Re: [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset"

Johannes Sixt [off-list ref] writes:

Christian Couder schrieb:

quoted

On Thu, Sep 17, 2009 at 9:24 AM, Johannes Sixt [off-list ref] wrote:

quoted

Junio C Hamano schrieb:

quoted

Johannes Sixt [off-list ref] writes:

 $ git stash
 $ git reset --hard $target
 $ git stash pop

It "can"? Do you say that you intend --merge-safe for something else in
addition to the above stash + reset --hard + stash pop sequence? What?

I think I am starting to understand.  The use case in a larger picture
would look like

    $ (edit/add/commit)+ to work towards something
    ... And you _finished_ that something.
    $ (edit/add)+ to work towards something else that is wonderful
    ... Now you notice that all the commits for that earlier something
    ... are crap and you would want to discard them, while still keeping
    ... changes for "something else that is wonderful".
    ... Luckily, you haven't committed anything you would want to keep,
    ... and you can afford to reset the tip commits away.
    $ git reset --keep-local-changes HEAD~7
    ... or howmanyever commits you want to discard.

The reset in this case is done purely to discard the crap, not to redo
them (you have something else you want to work on in your work tree and
index, and they are not fixups---if they were you wouldn't have resetted
but used "commit --amend" or "rebase -i").

It is more like switching branches but in this case you are switching to
your own branch immediately after rewinding that same branch.

In other words, as far as the index, the work tree and where HEAD will
point at are concerned, the new mode of reset works exactly like this:

    $ (edit/add)+ to work towards something wonderful
    ... notice that the work does not belong to the current branch
    ... and you would want to switch to another branch while carrying
    ... your local changes.
    $ git checkout another-branch

The only difference being that reset will stay on the same branch and
remove some commits from the tip of it, while checkout will leave the
original branch intact.

It makes sense that it has the same "safety" as "checkout" has when
switching branches; when you have modification in the index for a path,
and the path is different between switched-to commit and the current
commit, the command errors out with "cannot merge" (or a better message).

One drawback is that you can use this new mode of resetting only until you
make a commit that is part of the new "something else that is wonderful"
topic.  After that "git reset" with this new option is not useful for this
workflow, and you would need to stash then rebase -i then unstash.