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.
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.
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?
--
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