Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EGit » Missing Feature
Missing Feature [message #997287] Fri, 04 January 2013 23:02 Go to next message
Dennis Putnam is currently offline Dennis PutnamFriend
Messages: 52
Registered: January 2012
Member
I am just beginning to use Egit and have found what I think is a missing feature or flaw. As I move changed files to the staged area, I make commit comments describing the changes. However, I am not ready to commit and may quit Eclipse to return later. Unfortunately all the comments I entered are not saved and must be entered all over again. The ability to note changes as I go along is essential. Do I need to make the comments somewhere else that I can save then copy and paste when I am ready to commit? That is a waste when the comments should be saved in Eclipse until committed just like the files themselves. Perhaps it is just me doing something wrong. TIA
Re: Missing Feature [message #997305 is a reply to message #997287] Sat, 05 January 2013 14:32 Go to previous messageGo to next message
R Shapiro is currently offline R ShapiroFriend
Messages: 386
Registered: June 2011
Senior Member
What I do in this case is commit anyway, with a suitable message. I never intentionally exit Eclipse with uncommited changes. I can always amend the commit later, or do a reset to convert the commit back into working file changes. Or I can just continue on, keeping the half-done commit as a temporary checkpoint, and then reorganize all the new commits as a whole before merging from the work branch back to the master branch. As long as the commits I finally share with others, via push, are well-structured, it doesn't matter what I do with them internally.

Git's ability to use commits either as local check-points or as common share-points has totally changed my way of thinking about when to commit, to the extent that "not ready to commit" is no longer meaningful. It's one of the most important advantages it has over SVN.

As another option, you could stash the changes with a suitable message before exiting. Then when you restart, apply the stash to get the changes back, and when you finally commit, copy from the message from stash.

[Updated on: Sat, 05 January 2013 14:49]

Report message to a moderator

Re: Missing Feature [message #997354 is a reply to message #997305] Sun, 06 January 2013 20:49 Go to previous messageGo to next message
Dennis Putnam is currently offline Dennis PutnamFriend
Messages: 52
Registered: January 2012
Member
I guess I am still wrapping my head around the logic of this. In my mind the word commit has specific meaning as in databases and commit means irrevocable. If I understand you, even though I commit, as long as I don't push, the changes are not really immutable. In other words, when a commit is amended, say with changes to a particular file that has been previously modified and finally pushed, it will appear as only 1 version of that file in git. After the push the pre-amended version essentially is gone even though it was committed at one point?
Re: Missing Feature [message #997439 is a reply to message #997354] Mon, 07 January 2013 14:07 Go to previous messageGo to next message
R Shapiro is currently offline R ShapiroFriend
Messages: 386
Registered: June 2011
Senior Member
That's about right. Commits in Git are immutable but not irrevocable. In that sense it's a somewhat unfortunate term, carried over from older version control systems: you haven't really committed to anything until you push.

When you 'amend' the most recent commit on a given branch what you're really doing is dropping that commit and replacing it with a new one that that includes additional changes. From the user perspective it's as if the original commit had been modified.

Similarly if you 'reset' a branch back to an earlier commit with the 'soft' or 'mixed' option, all the commits since that one are removed from the branch but the corresponding file changes are not removed, leaving you free to reorganize those changes into an entirely different set of commits. The difference between soft and mixed has to do with the state of the index/staging-area. In a soft reset the index is left as it was: all the changes from all the dropped commits will still be in the index. If you did a new commit at this point, you would effectively be replacing all the dropped commits with one new one. In a 'mixed' reset, none of the changes from the dropped commits will be in the index. You're free at this point to starting adding them back, in whatever structure you want for the commits that will eventually be pushed. There's also a 'hard' reset, which will drop not only the commits but also the file (and index) changes. This will completely undo all the commits that were dropped. Btw the dropped commits will remain in the repository for awhile if for some reason you want to get at them again, though EGit doesn't provide an easy way to find them as far as I know. Eventually they'll be garbage-collected.

Amending commits and resetting branches are extremely useful features of Git once you get the hang of them, and they're both easily done in EGit. But you wouldn't want to do either on commits that had already been pushed.

[Updated on: Mon, 07 January 2013 14:38]

Report message to a moderator

Re: Missing Feature [message #997636 is a reply to message #997354] Mon, 07 January 2013 07:51 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26215
Registered: July 2009
Senior Member
Dennis,

Yes, I had the same problem/concern. When using CVS a commit was
sending stuff off to the server, which of course you don't want until
you're completely ready to actually commit. With git, commits happen
locally, and they are quite hard to undo locally, though maybe there's a
nice way I don't know about (that someone might explain to me). But
yes, you can amend a commit, and the result (locally) of that is
something that's just like you only did a single commit, so yes, when
you push, you push a single commit. It's a very nice feature, though I
miss being able to provide per-file comments as I commit, but I do like
that the entire set of related changes is a single commit so everyone
else will either see all my changes or none of them...


On 06/01/2013 9:49 PM, Dennis Putnam wrote:
> I guess I am still wrapping my head around the logic of this. In my
> mind the word commit has specific meaning as in databases and commit
> means irrevocable. If I understand you, even though I commit, as long
> as I don't push, the changes are not really immutable. In other words,
> when a commit is amended, say with changes to a particular file that
> has been previously modified and finally pushed, it will appear as
> only 1 version of that file in git. After the push the pre-amended
> version essentially is gone even though it was committed at one point?
Re: Missing Feature [message #997637 is a reply to message #997354] Mon, 07 January 2013 19:37 Go to previous messageGo to next message
Robin Rosenberg is currently offline Robin RosenbergFriend
Messages: 332
Registered: July 2009
Senior Member
Dennis Putnam skrev 2013-01-06 21.49:
> I guess I am still wrapping my head around the logic of this. In my mind the word commit has specific meaning as in databases and commit means irrevocable. If I understand
> you, even though I commit, as long as I don't push, the changes are not really immutable. In other words, when a commit is amended, say with changes to a particular file
> that has been previously modified and finally pushed, it will appear as only 1 version of that file in git. After the push the pre-amended version essentially is gone even
> though it was committed at one point?

In most databases committed data can be changed.

The first commit is immutable, but we point the branche at the new amended commit. A very small number of databases
also work this way and never ovewrite physical data.

-- robin
Re: Missing Feature [message #997710 is a reply to message #997636] Tue, 08 January 2013 15:32 Go to previous messageGo to next message
R Shapiro is currently offline R ShapiroFriend
Messages: 386
Registered: June 2011
Senior Member
Quote:
[commits] are quite hard to undo locally


Removing a random commit is hard. Removing the last N commits on a given branch, which I think is by far the most common case, is easy, assuming none of them have been pushed yet. This is what the 'reset' command is most commonly used for, and it's nicely supported in EGIt, though EGit doesn't quite cover all the cases that command-line Git does.

You can of course undo the effects of a any given commit by reverting it, but that's something else entirely.

Re: Missing Feature [message #998341 is a reply to message #997710] Wed, 09 January 2013 20:54 Go to previous message
Matthias Sohn is currently offline Matthias SohnFriend
Messages: 612
Registered: July 2009
Senior Member
R Shapiro wrote on Tue, 08 January 2013 10:32
Quote:
[commits] are quite hard to undo locally


Removing a random commit is hard. Removing the last N commits on a given branch, which I think is by far the most common case, is easy, assuming none of them have been pushed yet. This is what the 'reset' command is most commonly used for, and it's nicely supported in EGIt, though EGit doesn't quite cover all the cases that command-line Git does.

You can of course undo the effects of a any given commit by reverting it, but that's something else entirely.



There are at least 3 other ways to remove other commits:
- use interactive rebase using native git (egit doesn't support that yet) [1]
- in EGit create a new local branch based on the commit preceding the commit you want to remove, then cherry-pick all commits you still want from the branch you want to edit. This is a manual emulation of rebase interactive.
- in case the commit was already pushed to the server (published to other developers) or if you are using Gerrit code review when the commits have been already accepted in code review and submitted to the server side branch you can still undo a commit by using git revert [2] which creates a new commit undoing the change you are reverting. This is also supported in EGit: checkout the local branch where you want to revert the previous change, in the history view select the commit you want to undo and click "Revert"

[1] http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
[2] http://www.kernel.org/pub/software/scm/git/docs/git-revert.html

--
Matthias
Previous Topic:Understanding Branches
Next Topic:credentials passed to proxy server
Goto Forum:
  


Current Time: Fri Nov 21 18:09:54 GMT 2014

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

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