Re: [PATCH v5 4/7] reset: add option "--keep" to "git reset"

> Christian Couder <chriscool@tuxfamily.org> writes:
>
> >   B      B     C     D   --keep    (disallowed)
> >                          --merge    C      C     C
>
> For --keep this is the same as the first case (except that the "partially
> updated the index" happened to be "100% pertially") and it makes sense to
> disallow it.
>
> However, I think --merge _should_ have D (target) in all of the three in
> the result in this case, as I mentioned in my response to [PATCH 3/7]. 
> Is that "the bug" you talked about there?

> It also is tempting to say that we should forbid "reset --merge" without
> an unmerged entry in the index, but that wouldn't work.  A mergy
> operation would have left unmerged entries in the index initially before
> giving the control back to the user, but the user may have used "edit &&
> git add" to resolve them, and then decided that it is not worth
> committing.  By the time "reset --merge" is run, there may not be any
> unmerged path left in the index.
>
> I am suggesting extra safety measures primarily because I am worried that
> people will get confused by these two similar looking options that are
> meant for entirely different use cases.  An obvious alternative solution
> to avoid the confusion is not to add "--keep" in the first place.  While
> I think that is rather a cop-out than a solution, it might make more
> sense. It is hopeless to educate users to pick the right one, if even the
> author of the new option mistakenly thinks that "--keep is merely a
> better version of --merge".

> My preference is at this point to first have patches [1/7] to [3/7] to
> update "reset --merge" (I am not sure about the "--mixed in $GIT_DIR"
> change, though), with a new follow-up patch [3.5/7] to fix "reset
> --merge" to reset paths that were cloberred by the merge to the target
> (not HEAD), and start cooking these changes in 'pu' and then 'next'.