Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EGit / JGit » staged files commit
staged files commit [message #520133] Thu, 11 March 2010 09:29 Go to next message
No real name is currently offline No real nameFriend
Messages: 6
Registered: March 2010
Junior Member
Hi, i'm a newbie with EGit and i have a question:

i set up my workspace by importing a GIT repository and it worked fine. Now i make a change on a file and i want to commit it: if i right click on the file and select team --> commit, the commit works but i have the "staged" icon (the back-white star) close to the changed file within the eclipse explorer, but that file changes are not on the remote git , i just have it locally.
I worked with SVN and with it the commit are more easy to do. Maybe i miss something with GIT Smile

How can i commit changes on the remote git repository? could anyone help me?

thanks a lot
Re: staged files commit [message #520184 is a reply to message #520133] Thu, 11 March 2010 13:44 Go to previous messageGo to next message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
Hi ,

> i set up my workspace by importing a GIT repository and it worked fine.
> Now i make a change on a file and i want to commit it: if i right click on
> the file and select team --> commit, the commit works but i have the
> "staged" icon (the back-white star) close to the changed file within the
> eclipse explorer

Normally, after you have committed the change of the file, there should not
be the "staged" decoration anymore but the "tracked" decoration (Please see
the preferences for a description of the decoration). Maybe that is a
refresh problem?

> , but that file changes are not on the remote git , i just have it
> locally.

Git is a distributed version control system. That means that the import from
a remote location creates a complete repository on your local file system.
You can commit, branch and tag on this local repository. If you want to
bring your changes to a remote repository you normally use the command
"push". In EGit this is available at the context menu of a shared project.
Note that you may push to any remote repository, not necessarily the one you
imported from.

> I worked with SVN and with it the commit are more easy to do. Maybe i miss
> something with GIT :)

I recommend you to have a look at some introductory text, e.g.
http://progit.org/book/ Many things are different to SVN in a distributed
version control system like Git.

Stefan
Re: staged files commit [message #520205 is a reply to message #520184] Thu, 11 March 2010 14:50 Go to previous messageGo to next message
No real name is currently offline No real nameFriend
Messages: 6
Registered: March 2010
Junior Member
Hi, thanks a lot for your help.

Initially (not yet modified file) decoration is "tracked". When i modify that file i have "dirty" decoration on it. When i commit it with contextual menu, the decoration changes to "staged" (black-withe star..) and remains with this decoration even if i try to refresh the project.

Where is the problem? maybe, to get "tracked" on file, i need to "push" the file (or the whole project?) to the remote repository, is it possible?

thanks again
Re: staged files commit [message #520388 is a reply to message #520205] Fri, 12 March 2010 08:28 Go to previous messageGo to next message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
> Initially (not yet modified file) decoration is "tracked". When i modify
> that file i have "dirty" decoration on it. When i commit it with
> contextual menu, the decoration changes to "staged" (black-withe star..)
> and remains with this decoration even if i try to refresh the project.

This is strange. After you commit you should have the decoration "tracked".
Which version of EGit do you use? What happens if you try to commit again,
is the file still on the list of files to be comitted?

> Where is the problem? maybe, to get "tracked" on file, i need to "push"
> the file (or the whole project?) to the remote repository, is it possible?

No, this states have nothing to do with the remote repository. If you want
to push, you have to push the whole repository, because each commit changes
the state of the whole repository.

Stefan
Re: staged files commit [message #520441 is a reply to message #520388] Fri, 12 March 2010 11:57 Go to previous messageGo to next message
No real name is currently offline No real nameFriend
Messages: 6
Registered: March 2010
Junior Member
I have installed (through Eclipse Install New Software..) the version got here:

http://download.eclipse.org/egit/updates

After the commit the decoration of some files "dirty" become "tracked" and others become "staged", i can't understand the meaning of it. If i try to commit again egit tell that i have nothing to commit.

How can i see the list of files to be committed?

I tried to commit a single file but i can't commit single file but all the files in a single commit..by this way i have a single commit for all files, it would be nice to commit one file at time..how can i do that?

thanks a lot for your patience
Re: staged files commit [message #525416 is a reply to message #520441] Tue, 06 April 2010 14:22 Go to previous messageGo to next message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
>
> After the commit the decoration of some files "dirty" become "tracked" and
> others become "staged", i can't understand the meaning of it. If i try to
> commit again egit tell that i have nothing to commit.

If egit tells you that you have nothing to commit, although there are files
with the "staged" decoration, there is a refresh problem or a bug. Could you
describe step by step what you are doing?

> How can i see the list of files to be committed?

You can see the list of files in the commit dialog.

> I tried to commit a single file but i can't commit single file but all the
> files in a single commit..by this way i have a single commit for all
> files, it would be nice to commit one file at time..how can i do that?

You can select the files you want to commit in the commit dialog, see also
http://wiki.eclipse.org/EGit/User_Guide#Committing_changes Note that it is
a great feature of git that you can commit many files within one commit. By
this you can logically group changes which belong together.
Re: staged files commit [message #526962 is a reply to message #520133] Tue, 13 April 2010 15:11 Go to previous messageGo to next message
Joe Shelton is currently offline Joe SheltonFriend
Messages: 2
Registered: April 2010
Junior Member
I am having the same problem with confusion between dirty/staged states of a modified file after a commit. I'm pretty sure it's not a refresh issue. I am also new to both git and Egit, but I did a little investigation using git status from the command line.

Starting with a clean, tracked file tree, git status says nothing changed or staged, as it should.

After making a change to a file and saving, it gets a "dirty" decoration in Eclipse. git status says the file is "Changed but not updated".

After performing a commit in Eclipse, the "dirty" decoration is removed and "staged" is added. git status has file under "Changes to be committed:". This means staged, right?

At this point, I have to stop using Eclipse and do a commit from the command line, in order to get the staged file commited. Trying to commit again in Eclipse just gives the "nothing to commit" message.

OS: Mac OS X v10.5.8
Eclipse: v3.5.2
EGit/JGit: v0.7.1
Re: staged files commit [message #529452 is a reply to message #526962] Sun, 25 April 2010 18:40 Go to previous messageGo to next message
James Revillini is currently offline James RevilliniFriend
Messages: 10
Registered: April 2010
Junior Member
Same deal here. Whew ... thought I was going nuts. I'm on Aptana Studio 2.0 standalone on Ubuntu 10.04. EGit 0.7.1.

What I don't get is how the history (right-click project > Team > Show in Resource History) can show all the things I've committed in different commits, but when I 'git status' on the command line, all those files I've committed are listed as modified/staged. 'git commit -a' indeed lists them all as having changes ready to commit.

Also, history (right-click project > Team > Show in Resource History) will show, for each item in the history, all the actions for each file, be it adds, deletes, ignores - whatever. 'git log' on the CL shows those commits but not files affected by the commit.

I don't know a heck of a lot about git yet, so I'll just ask: is EGit making all these commits to the index and not to the repo? Does git have the ability to track commits to the index (like a subcommit or something) and commits to the repo? If so, does EGit have some other hidden thing to make a true commit to the repo?

Thoroughly Confused,
James

[Updated on: Sun, 25 April 2010 18:42]

Report message to a moderator

Re: staged files commit [message #529455 is a reply to message #520133] Sun, 25 April 2010 19:16 Go to previous messageGo to next message
James Revillini is currently offline James RevilliniFriend
Messages: 10
Registered: April 2010
Junior Member
OK I think I figured it out. I think it's permission changes. What?! Yes, that's what I said.

So like I said, I had a bunch of 'staged' (*) symbols on just about everything, and the commit dialog was showing nothing to commit. So I went to command line, ran a 'git commit,' typed my message, and made the commit. I went back into Aptana/Eclipse and all the little icons went to the happy yellow can (I love the happy yellow can, by the way). I again reviewed the history. Nothing different about the latest commit. I clicked on one of the files - .htaccess to be specific - and read the message about it. Lo and behold:

---------------------------------- .htaccess ----------------------------------
old mode 100644new mode 100755
index d635769..d635769


OK, first of all, does the git repo really care about permissions?! Wouldn't the permissions inherit whatever they are on the target system when someone clones the repo?

Second, should I file a bug about the commit dialog in EGit? Seems it should check the permissions and allow a commit of a file whose permissions have changed but whose content has not necessarily changed. The project explorer clearly knows about permission changes. Did the dialog devs try to write their own 'is_this_dirty' method for just the dialog?

Happily Buried in Yellow Cans,
James
Re: staged files commit [message #529716 is a reply to message #529455] Mon, 26 April 2010 22:04 Go to previous messageGo to next message
Robin Rosenberg is currently offline Robin RosenbergFriend
Messages: 332
Registered: July 2009
Senior Member
James Revillini wrote:

> OK I think I figured it out. I think it's permission changes. What?!
> Yes, that's what I said.
>
> So like I said, I had a bunch of 'staged' (*) symbols on just about
> everything, and the commit dialog was showing nothing to commit. So I
> went to command line, ran a 'git commit,' typed my message, and made the
> commit. I went back into Aptana/Eclipse and all the little icons went to
> the happy yellow can (I love the happy yellow can, by the way). I again
> reviewed the history. Nothing different about the latest commit. I
> clicked on one of the files - .htaccess to be specific - and read the
> message about it. Lo and behold:
>
> ---------------------------------- .htaccess
> ---------------------------------- old mode 100644new mode 100755
> index d635769..d635769
>
> OK, first of all, does the git repo really care about permissions?!
> Wouldn't the permissions inherit whatever they are on the target system
> when someone clones the repo?

The only bit we care about it the execute flag on the owner side. Group
and other always have the same value. Is this on Windows and how exactly
did you get to this situation.

>
> Second, should I file a bug about the commit dialog in EGit? Seems it
> should check the permissions and allow a commit of a file whose
> permissions have changed but whose content has not necessarily changed.
It should, though on Windows we should possibly ignore changes. File a bug
report.

> The project explorer clearly knows about permission changes. Did the
> dialog devs try to write their own 'is_this_dirty' method for just the
> dialog?
Hmmm. Same logic should apply, I think.

-- robin
Re: staged files commit [message #529731 is a reply to message #529716] Tue, 27 April 2010 01:48 Go to previous messageGo to next message
James Revillini is currently offline James RevilliniFriend
Messages: 10
Registered: April 2010
Junior Member
Robin Rosenberg wrote on Mon, 26 April 2010 18:04
James Revillini wrote:

> OK I think I figured it out. I think it's permission changes. What?!
> Yes, that's what I said.
>
> So like I said, I had a bunch of 'staged' (*) symbols on just about
> everything, and the commit dialog was showing nothing to commit. So I
> went to command line, ran a 'git commit,' typed my message, and made the
> commit. I went back into Aptana/Eclipse and all the little icons went to
> the happy yellow can (I love the happy yellow can, by the way). I again
> reviewed the history. Nothing different about the latest commit. I
> clicked on one of the files - .htaccess to be specific - and read the
> message about it. Lo and behold:
>
> ---------------------------------- .htaccess
> ---------------------------------- old mode 100644new mode 100755
> index d635769..d635769
>
> OK, first of all, does the git repo really care about permissions?!
> Wouldn't the permissions inherit whatever they are on the target system
> when someone clones the repo?

The only bit we care about it the execute flag on the owner side. Group
and other always have the same value. Is this on Windows and how exactly
did you get to this situation.



This is Ubuntu 10.04 with Aptana 2.0 standalone. I figured out what really does it. I had to chown nobody:/ the whole directory I'm working in due to the way Wordpress determines if you can upload plugins, and then chmod it to 777 so I could still write to it as the logged in user (well, there's probably a way better way, but I'm not a linux power user, so it is what it is). After you do that, everything gets screwy as I described. In trying to reproduce, if I did not do the chown/chmod thing, all worked normally.

Robin Rosenberg wrote on Mon, 26 April 2010 18:04

>
> Second, should I file a bug about the commit dialog in EGit? Seems it
> should check the permissions and allow a commit of a file whose
> permissions have changed but whose content has not necessarily changed.
It should, though on Windows we should possibly ignore changes. File a bug
report.



Still think I should do that since it's an oddball setup? I mean, I do still kind of think it's a bug, but I don't even really know how to describe the problem now that it seems it only happens when the current user doesn't own the directory, but can still make changes to it.

Robin Rosenberg wrote on Mon, 26 April 2010 18:04

> The project explorer clearly knows about permission changes. Did the
> dialog devs try to write their own 'is_this_dirty' method for just the
> dialog?
Hmmm. Same logic should apply, I think.

-- robin

Re: staged files commit [message #530187 is a reply to message #529731] Wed, 28 April 2010 18:41 Go to previous messageGo to next message
Robin Rosenberg is currently offline Robin RosenbergFriend
Messages: 332
Registered: July 2009
Senior Member
James Revillini wrote:

> Robin Rosenberg wrote on Mon, 26 April 2010 18:04
>> James Revillini wrote:
>>
>> > OK I think I figured it out. I think it's permission changes. What?!
>> > Yes, that's what I said.
>> >
>> > So like I said, I had a bunch of 'staged' (*) symbols on just about
>> > everything, and the commit dialog was showing nothing to commit. So I
>> > went to command line, ran a 'git commit,' typed my message, and made
>> > the
>> > commit. I went back into Aptana/Eclipse and all the little icons went
>> > to
>> > the happy yellow can (I love the happy yellow can, by the way). I
>> > again
>> > reviewed the history. Nothing different about the latest commit. I
>> > clicked on one of the files - .htaccess to be specific - and read the
>> > message about it. Lo and behold:
>> >
>> > ---------------------------------- .htaccess
>> > ---------------------------------- old mode 100644new mode 100755
>> > index d635769..d635769
>> >
>> > OK, first of all, does the git repo really care about permissions?!
>> > Wouldn't the permissions inherit whatever they are on the target system
>> > when someone clones the repo?
>>
>> The only bit we care about it the execute flag on the owner side. Group
>> and other always have the same value. Is this on Windows and how exactly
>> did you get to this situation.
>
>
> This is Ubuntu 10.04 with Aptana 2.0 standalone. I figured out what
> really does it. I had to chown nobody:/ the whole directory I'm working
> in due to the way Wordpress determines if you can upload plugins, and then
> chmod it to 777 so I could still write to it as the logged in user (well,
> there's probably a way better way, but I'm not a linux power user, so it
> is what it is). After you do that, everything gets screwy as I described.
> In trying to reproduce, if I did not do the chown/chmod thing, all worked
> normally.

You set the execute bit and EGit picks up the change. Go back and do it
right this time. chmod 777 is *never* a good idea for more reasons than
this.

-- robin
Re: staged files commit [message #531739 is a reply to message #530187] Thu, 06 May 2010 01:23 Go to previous messageGo to next message
James Revillini is currently offline James RevilliniFriend
Messages: 10
Registered: April 2010
Junior Member
Robin Rosenberg wrote on Wed, 28 April 2010 14:41

...
You set the execute bit and EGit picks up the change. Go back and do it right this time.
...



Regardless of whether or not I'm doing things right, shouldn't it check in what I've chmodded things and then stop bugging me that the working copy is different than the repo copy?
Re: staged files commit [message #531742 is a reply to message #520133] Thu, 06 May 2010 01:49 Go to previous messageGo to next message
James Revillini is currently offline James RevilliniFriend
Messages: 10
Registered: April 2010
Junior Member
Here, look. Even after chowning the whole thing back to the user I'm logged in as and chmodding the directory recursively to 766, EGit still knows about the change but won't check it in.

git commit -a at the command line yields stuff like:

$ git commit -a -m "trying to fix issue in Aptana where it won't check in permission changes"
[master 5d2ac8b] trying to fix issue in Aptana where it won't check in permission changes
 5 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100644 => 100755 .gitignore
...
...
...


In Aptana, I'm back to yellow cans.

Can you help me summarize the bug so when I submit it, they don't throw it back at me on a technicality? I know I won't phrase it write, but I can write up the summary and reproduce procedure.

Thanks.
Re: staged files commit [message #532311 is a reply to message #531739] Fri, 07 May 2010 21:51 Go to previous messageGo to next message
Robin Rosenberg is currently offline Robin RosenbergFriend
Messages: 332
Registered: July 2009
Senior Member
James Revillini wrote:

> Robin Rosenberg wrote on Wed, 28 April 2010 14:41
>> ...
>> You set the execute bit and EGit picks up the change. Go back and do it
>> right this time. ...
>
>
> Regardless of whether or not I'm doing things right, shouldn't it check in
> what I've chmodded things and then stop bugging me that the working copy
> is different than the repo copy?

If you check it in, then yes, it should stop bugging you.

-- robin
Re: staged files commit [message #532538 is a reply to message #520133] Mon, 10 May 2010 12:29 Go to previous message
Phil is currently offline PhilFriend
Messages: 7
Registered: July 2009
Junior Member
Hi, just wanted to add my 2p worth...

There definitely appears to be an issue here as this bug has been reported on at least three separate occasions: 295939, 307560 and 312164.

Quote:
If you check it in, then yes, it should stop bugging you.


I think the problem here is that eclipse is displaying the file as modified (because of the permissions change) but you are not able to commit that change using eGit itself - to rectify the problem you must do a manual commit from the command line.

James has written a good walk through of how to reproduce the error in #312164.
Re: staged files commit [message #578158 is a reply to message #520184] Thu, 11 March 2010 14:50 Go to previous message
No real name is currently offline No real nameFriend
Messages: 6
Registered: March 2010
Junior Member
Hi, thanks a lot for your help.

Initially (not yet modified file) decoration is "tracked". When i modify that file i have "dirty" decoration on it. When i commit it with contextual menu, the decoration changes to "staged" (black-withe star..) and remains with this decoration even if i try to refresh the project.

Where is the problem? maybe, to get "tracked" on file, i need to "push" the file (or the whole project?) to the remote repository, is it possible?

thanks again
Re: staged files commit [message #578184 is a reply to message #520205] Fri, 12 March 2010 08:28 Go to previous message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
> Initially (not yet modified file) decoration is "tracked". When i modify
> that file i have "dirty" decoration on it. When i commit it with
> contextual menu, the decoration changes to "staged" (black-withe star..)
> and remains with this decoration even if i try to refresh the project.

This is strange. After you commit you should have the decoration "tracked".
Which version of EGit do you use? What happens if you try to commit again,
is the file still on the list of files to be comitted?

> Where is the problem? maybe, to get "tracked" on file, i need to "push"
> the file (or the whole project?) to the remote repository, is it possible?

No, this states have nothing to do with the remote repository. If you want
to push, you have to push the whole repository, because each commit changes
the state of the whole repository.

Stefan
Re: staged files commit [message #578197 is a reply to message #520388] Fri, 12 March 2010 11:57 Go to previous message
No real name is currently offline No real nameFriend
Messages: 6
Registered: March 2010
Junior Member
I have installed (through Eclipse Install New Software..) the version got here:

http://download.eclipse.org/egit/updates

After the commit the decoration of some files "dirty" become "tracked" and others become "staged", i can't understand the meaning of it. If i try to commit again egit tell that i have nothing to commit.

How can i see the list of files to be committed?

I tried to commit a single file but i can't commit single file but all the files in a single commit..by this way i have a single commit for all files, it would be nice to commit one file at time..how can i do that?

thanks a lot for your patience
Re: staged files commit [message #578848 is a reply to message #578197] Tue, 06 April 2010 14:22 Go to previous message
Stefan Lay is currently offline Stefan LayFriend
Messages: 342
Registered: July 2009
Senior Member
>
> After the commit the decoration of some files "dirty" become "tracked" and
> others become "staged", i can't understand the meaning of it. If i try to
> commit again egit tell that i have nothing to commit.

If egit tells you that you have nothing to commit, although there are files
with the "staged" decoration, there is a refresh problem or a bug. Could you
describe step by step what you are doing?

> How can i see the list of files to be committed?

You can see the list of files in the commit dialog.

> I tried to commit a single file but i can't commit single file but all the
> files in a single commit..by this way i have a single commit for all
> files, it would be nice to commit one file at time..how can i do that?

You can select the files you want to commit in the commit dialog, see also
http://wiki.eclipse.org/EGit/User_Guide#Committing_changes Note that it is
a great feature of git that you can commit many files within one commit. By
this you can logically group changes which belong together.
Re: staged files commit [message #579766 is a reply to message #529455] Mon, 26 April 2010 22:04 Go to previous message
Robin Rosenberg is currently offline Robin RosenbergFriend
Messages: 332
Registered: July 2009
Senior Member
James Revillini wrote:

> OK I think I figured it out. I think it's permission changes. What?!
> Yes, that's what I said.
>
> So like I said, I had a bunch of 'staged' (*) symbols on just about
> everything, and the commit dialog was showing nothing to commit. So I
> went to command line, ran a 'git commit,' typed my message, and made the
> commit. I went back into Aptana/Eclipse and all the little icons went to
> the happy yellow can (I love the happy yellow can, by the way). I again
> reviewed the history. Nothing different about the latest commit. I
> clicked on one of the files - .htaccess to be specific - and read the
> message about it. Lo and behold:
>
> ---------------------------------- .htaccess
> ---------------------------------- old mode 100644new mode 100755
> index d635769..d635769
>
> OK, first of all, does the git repo really care about permissions?!
> Wouldn't the permissions inherit whatever they are on the target system
> when someone clones the repo?

The only bit we care about it the execute flag on the owner side. Group
and other always have the same value. Is this on Windows and how exactly
did you get to this situation.

>
> Second, should I file a bug about the commit dialog in EGit? Seems it
> should check the permissions and allow a commit of a file whose
> permissions have changed but whose content has not necessarily changed.
It should, though on Windows we should possibly ignore changes. File a bug
report.

> The project explorer clearly knows about permission changes. Did the
> dialog devs try to write their own 'is_this_dirty' method for just the
> dialog?
Hmmm. Same logic should apply, I think.

-- robin
Re: staged files commit [message #579778 is a reply to message #529716] Tue, 27 April 2010 01:48 Go to previous message
James Revillini is currently offline James RevilliniFriend
Messages: 10
Registered: April 2010
Junior Member
Robin Rosenberg wrote on Mon, 26 April 2010 18:04
> James Revillini wrote:
>
> > OK I think I figured it out. I think it's permission changes. What?!
> > Yes, that's what I said.
> >
> > So like I said, I had a bunch of 'staged' (*) symbols on just about
> > everything, and the commit dialog was showing nothing to commit. So I
> > went to command line, ran a 'git commit,' typed my message, and made the
> > commit. I went back into Aptana/Eclipse and all the little icons went to
> > the happy yellow can (I love the happy yellow can, by the way). I again
> > reviewed the history. Nothing different about the latest commit. I
> > clicked on one of the files - .htaccess to be specific - and read the
> > message about it. Lo and behold:
> >
> > ---------------------------------- .htaccess
> > ---------------------------------- old mode 100644new mode 100755
> > index d635769..d635769
> >
> > OK, first of all, does the git repo really care about permissions?!
> > Wouldn't the permissions inherit whatever they are on the target system
> > when someone clones the repo?
>
> The only bit we care about it the execute flag on the owner side. Group
> and other always have the same value. Is this on Windows and how exactly
> did you get to this situation.


This is Ubuntu 10.04 with Aptana 2.0 standalone. I figured out what really does it. I had to chown nobody:/ the whole directory I'm working in due to the way Wordpress determines if you can upload plugins, and then chmod it to 777 so I could still write to it as the logged in user (well, there's probably a way better way, but I'm not a linux power user, so it is what it is). After you do that, everything gets screwy as I described. In trying to reproduce, if I did not do the chown/chmod thing, all worked normally.

Robin Rosenberg wrote on Mon, 26 April 2010 18:04
> >
> > Second, should I file a bug about the commit dialog in EGit? Seems it
> > should check the permissions and allow a commit of a file whose
> > permissions have changed but whose content has not necessarily changed.
> It should, though on Windows we should possibly ignore changes. File a bug
> report.


Still think I should do that since it's an oddball setup? I mean, I do still kind of think it's a bug, but I don't even really know how to describe the problem now that it seems it only happens when the current user doesn't own the directory, but can still make changes to it.

Robin Rosenberg wrote on Mon, 26 April 2010 18:04
> > The project explorer clearly knows about permission changes. Did the
> > dialog devs try to write their own 'is_this_dirty' method for just the
> > dialog?
> Hmmm. Same logic should apply, I think.
>
> -- robin
Re: staged files commit [message #579838 is a reply to message #579778] Wed, 28 April 2010 18:41 Go to previous message
Robin Rosenberg is currently offline Robin RosenbergFriend
Messages: 332
Registered: July 2009
Senior Member
James Revillini wrote:

> Robin Rosenberg wrote on Mon, 26 April 2010 18:04
>> James Revillini wrote:
>>
>> > OK I think I figured it out. I think it's permission changes. What?!
>> > Yes, that's what I said.
>> >
>> > So like I said, I had a bunch of 'staged' (*) symbols on just about
>> > everything, and the commit dialog was showing nothing to commit. So I
>> > went to command line, ran a 'git commit,' typed my message, and made
>> > the
>> > commit. I went back into Aptana/Eclipse and all the little icons went
>> > to
>> > the happy yellow can (I love the happy yellow can, by the way). I
>> > again
>> > reviewed the history. Nothing different about the latest commit. I
>> > clicked on one of the files - .htaccess to be specific - and read the
>> > message about it. Lo and behold:
>> >
>> > ---------------------------------- .htaccess
>> > ---------------------------------- old mode 100644new mode 100755
>> > index d635769..d635769
>> >
>> > OK, first of all, does the git repo really care about permissions?!
>> > Wouldn't the permissions inherit whatever they are on the target system
>> > when someone clones the repo?
>>
>> The only bit we care about it the execute flag on the owner side. Group
>> and other always have the same value. Is this on Windows and how exactly
>> did you get to this situation.
>
>
> This is Ubuntu 10.04 with Aptana 2.0 standalone. I figured out what
> really does it. I had to chown nobody:/ the whole directory I'm working
> in due to the way Wordpress determines if you can upload plugins, and then
> chmod it to 777 so I could still write to it as the logged in user (well,
> there's probably a way better way, but I'm not a linux power user, so it
> is what it is). After you do that, everything gets screwy as I described.
> In trying to reproduce, if I did not do the chown/chmod thing, all worked
> normally.

You set the execute bit and EGit picks up the change. Go back and do it
right this time. chmod 777 is *never* a good idea for more reasons than
this.

-- robin
Re: staged files commit [message #580033 is a reply to message #530187] Thu, 06 May 2010 01:23 Go to previous message
James Revillini is currently offline James RevilliniFriend
Messages: 10
Registered: April 2010
Junior Member
Robin Rosenberg wrote on Wed, 28 April 2010 14:41
> ...
> You set the execute bit and EGit picks up the change. Go back and do it right this time.
> ...


Regardless of whether or not I'm doing things right, shouldn't it check in what I've chmodded things and then stop bugging me that the working copy is different than the repo copy?
Re: staged files commit [message #580099 is a reply to message #580033] Fri, 07 May 2010 21:51 Go to previous message
Robin Rosenberg is currently offline Robin RosenbergFriend
Messages: 332
Registered: July 2009
Senior Member
James Revillini wrote:

> Robin Rosenberg wrote on Wed, 28 April 2010 14:41
>> ...
>> You set the execute bit and EGit picks up the change. Go back and do it
>> right this time. ...
>
>
> Regardless of whether or not I'm doing things right, shouldn't it check in
> what I've chmodded things and then stop bugging me that the working copy
> is different than the repo copy?

If you check it in, then yes, it should stop bugging you.

-- robin
Previous Topic:Replace with git index missing?
Next Topic:staged files commit
Goto Forum:
  


Current Time: Fri Mar 29 01:50:10 GMT 2024

Powered by FUDForum. Page generated in 0.03090 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top