Home » Eclipse Projects » EGit / JGit » staged files commit
|
Re: staged files commit [message #520184 is a reply to message #520133] |
Thu, 11 March 2010 13:44 |
Stefan Lay 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 #526962 is a reply to message #520133] |
Tue, 13 April 2010 15:11 |
Joe Shelton 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 |
James Revillini 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 |
James Revillini 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 |
Robin Rosenberg 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 |
James Revillini 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 |
Robin Rosenberg 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 #579766 is a reply to message #529455] |
Mon, 26 April 2010 22:04 |
Robin Rosenberg 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 |
James Revillini 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 |
Robin Rosenberg 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
|
|
| | |
Goto Forum:
Current Time: Thu Sep 26 14:34:02 GMT 2024
Powered by FUDForum. Page generated in 0.08638 seconds
|