On mardi 19 janvier 2010, Junio C Hamano wrote:
> Christian Couder <chriscool@xxxxxxxxxxxxx> writes:
> > The purpose of this new option is to discard some of the
> > last commits but to keep current changes in the work tree.
> >
> > The use case is when you work on something and commit
> > that work. And then you work on something else that touches
> > other files, but you don't commit it yet. Then you realize
> > that what you commited when you worked on the first thing
> > is not good or belongs to another branch.
> >
> > So you want to get rid of the previous commits (at least in
> > the current branch) but you want to make sure that you keep
> > the changes you have in the work tree.
>
> You did this:
>
> git checkout master
> work; git commit ; work; git commit ; work; git commit
> edit ; git add ; ... (but not commit)
>
> and noticed the three commits should not be on master but on a new
> branch.
>
> I think we currently teach users to do something like this:
>
> git stash
> git branch topic
> git reset --hard HEAD~3
> git stash pop
>
> Instead you want to do this:
>
> git branch topic
> git reset --keep HEAD~3
>
> Surely you halved the number of command involved, but is this really an
> improvement? At least I can visualize (and more importantly, explain to
> new users) how the "stash, flip and unstash" works, why it is safe, and
> how to recover when "pop" stops in conflicts, but I have no confidence in
> explaining what "reset --keep" does and how to recover when it refuses to
> work to new users.
Of course new users should be told about "git stash" before being told
about "git reset --keep" and "git reset --merge". These 2 options are
mostly for advanced users who want shortcuts and are ready to learn a few
more options to speed up some of their common tasks.
Commit 9e8eceab ("Add 'merge' mode to 'git reset'", 2008-12-01), ended with:
-------------------
Yes, yes, with a dirty tree you could always do
git stash
git reset --hard
git stash apply
instead, but isn't "git reset --merge" a nice way to handle one
particular simple case?
-------------------
and I claim that the same is true for "--keep". It is just a nice way to
handle one particular simple case.
> Another way to accomplish the same thing might be:
>
> git branch -m topic
> git checkout -b master HEAD~3
>
> and with the same number of commands, conceptually it may be easier to
> understand than "reset --keep". What you committed so far belongs to
> another branch "topic", so you name the current history that way, and
> then you switch branches with "checkout" that keeps your local
> modifications. It also opens the possibility of retrying with "-m" after
> checkout refuses to acti, to take the same mix-up risk CVS/SVN users
> have, if you are very confident that your local change conflicts only
> minimally with the change made on the topic and you can resolve them.
Sorry but I don't find that easier to understand. On the contrary I find
awkward to have to rename the current branch first.
My first reaction when I realize that my current work belongs to another
branch is just to create another branch with a good name, and then I try to
find a way to make the new branch clean. It would be strange and perhaps a
little bit unsafe, at least for me, to have to rename the current branch
and then recreate it with some good content.
> Of course, when you are not interested in keeping the topmost commits at
> all, you either
>
> git stash ; git reset --hard HEAD~3 ; git stash pop
>
> or
>
> git reset --keep HEAD~3
>
> but even in this case, I think "stash, flip and unstash" is easier to
> explain, especially when teaching what to do if things go wrong.
>
> I dunno. Is this really an useful addition that helps real-world
> workflows and is worth a five patch series, or is this just "because we
> can" patch?
I know that I will use the new option. At least I will use it much more
than --merge that I never used at $dayjob, probably because I don't merge a
lot of stuff.
Best regards,
Christian.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html