Re: [RFC 0/3] Make git more user-friendly during a merge conflict

David Kastrup [off-list ref] writes:

Stephen Leake [off-list ref] writes:

quoted

David Kastrup [off-list ref] writes:

quoted

Stephen Leake [off-list ref] writes:

quoted

David Kastrup [off-list ref] writes:

quoted

"do the right thing" commands also tend to do the wrong thing
occasionally with potentially disastrous results when they are used
in scripts where the followup actions rely on the actual result.

That is bad, and should not be allowed. On the other hand, I have yet
to see an actual use case of bad behavior in this discussion.

Huh.

<http://permalink.gmane.org/gmane.comp.version-control.git/242744>

That's about backward incompatibility, which is bad, but not what I was
talking about above.

No, it isn't.  I quote:

    I sometimes run "git reset" during a merge to only reset the index
    and then examine the changes introduced by the merge. With your
    changes, someone doing so would abort the merge and discard the
    merge resolution.  I very rarely do this, but even rarely, I
    wouldn't like Git to start droping data silently for me ;-).

You should not make statements like "I have yet to see an actual use
case of bad behavior in this discussion" when you actually mean "I have
not yet seen anything I would be interested in doing myself".

Clearly I misunderstood your point. Merely repeating the same statement
that I misunderstood, and adding a misunderstanding of what I said, is
not helpful.

So let me see if I can expand on your use case:

- you do 'git merge', which results in conflicts

- you edit some workspace files to resolve some of those conflicts 

    (I added this step later, since it was implied but not explicit)

- you do 'git reset', intending 'git reset --mixed' (because that is the
  current default)

    Actually, I can't find a precise definition of 'git reset'. Here is
    the synopsis from the man page for 'git-reset' (from git 1.7.9):

       git reset [-q] [<commit>] [--] <paths>...
       git reset (--patch | -p) [<commit>] [--] [<paths>...]
       git reset (--soft | --mixed | --hard | --merge | --keep) [-q] [<commit>]

    In 'git reset', there is no path, so it must be the second or third
    form. But those _require_ one of the -- options. So 'git reset' is
    illegal. Clearly something is wrong here; apparently the third line
    should be:

       git reset [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>]

    with '--mixed' as the default, as is stated later. (perhaps the
    original intent was to not have a default for the third form, but
    that got changed sometime?).

    This command "resets the index" but not the working tree. I'm not
    clear what "reset the index" means here; does it mean "remove all
    entries from the index", or "reset the index to some previous
    state"? In other man pages, "reset" can have either meaning
    depending on context.

- then you "examine changes introduced by the merge". I don't know what
  this means in detail. 

    Before resetting the index, you could diff a workspace file against
    either HEAD or index. Now you can only diff against HEAD, so I don't
    understand why you wanted to reset the index. That's not relevant to
    this use case; I'll just accept that resetting the index is a useful
    thing to do here. But I would like to understand why.

- with the "do the right thing" patch, 'git reset' does 'git reset
  --merge' instead

    That "Resets the index and updates the files in the working tree
    that are different between <commit> and HEAD". 

    "<commit>" in this case defaults to HEAD, so the working tree is
    not changed.

So as I understand it, this does _not_ lose your conflict resolutions.

In fact, it now seems that 'git reset --mixed' is always the same as
'git reset --merge'. So I must be missing something!

-- 
-- Stephe