Home » Eclipse Projects » EGit / JGit » Missing Feature
|
| Re: Missing Feature [message #997305 is a reply to message #997287] |
Sat, 05 January 2013 14:32   |
 R Shapiro
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 #997439 is a reply to message #997354] |
Mon, 07 January 2013 14:07 |
R Shapiro
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 |
Ed Merks
Messages: 33141
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?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: Missing Feature [message #998341 is a reply to message #997710] |
Wed, 09 January 2013 20:54 |
Matthias Sohn
Messages: 1268
Registered: July 2009 |
Senior Member |
|
|
R Shapiro wrote on Tue, 08 January 2013 10:32Quote: [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
|
|
|
Goto Forum:
Current Time: Thu Apr 25 20:19:05 GMT 2024
Powered by FUDForum. Page generated in 0.04051 seconds |
] 
Search
Help
Register
Login
Home
