Re: [PATCH v2 1/5] reset: add option "--keep" to "git reset"

On mardi 19 janvier 2010, Junio C Hamano wrote:

Christian Couder [off-list ref] writes:

quoted

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.