Re: Opinions on changing add/add conflict resolution?

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 12, 2018, 21:35 UTC
Message-ID: <20180312213521.GB58506@aiede.svl.corp.google.com>
In-Reply-To: <CABPp-BEdh+UOCpFn5Y1_RydR==dDHWTeNtBub+pPjH_06Ub28w@mail.gmail.com>

Hi again,

Elijah Newren wrote:

> On Mon, Mar 12, 2018 at 11:47 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 12 quoted lines

>> Would this behavior be configurable or unconditional?  I suspect I
>> would want it turned off in my own use.
>>
>> On the other hand, in the case of wild difference between the two
>> files, skipping the two-way merge and just writing one of the versions
>> to the worktree (like we do for binary files) sounds like something I
>> would like in my own use.
>
> I think you just said the exact opposite thing in these last two
> paragraphs; that you wouldn't want my proposed behavior and that you'd
> want it.  I suspect that may mean that I misunderstood something you
> said here.  Could you clarify?

Sorry for the lack of clarity. My understanding was that the proposed behavior was to write two files:

	${path}~HEAD
	${path}~MERGE

My proposal is instead to write one file:

	${path}

with the content that would have gone to ${path}~HEAD. This is what already happens when trying to merge binary files.

[...]

Show 6 quoted lines

>> Can you add something more about the motivation to the commit message?
>> E.g. is this about performance, interaction with some tools, to
>> support some particular workflow, etc?
>
> To be honest, I'm a little unsure how without even more excessive and
> repetitive wording across commits.

Simplest way IMHO is to just put the rationale in patch 5/5. :) In other words, explain the rationale for the end-user facing change in the same patch that changes the end-user facing behavior.

Show 6 quoted lines

>                                     Let me attempt here, and maybe you
> can suggest how to change my commit messages?
>
>   * When files are wildly dissimilar -- as you mentioned -- it'd be
> easier for users to resolve conflicts if we wrote files out to
> separate paths instead of two-way merging them.

Today what we do (in both the wildly-dissimilar case and the less-dissimilar case) is write one proposed resolution to the worktree and put the competing versions in the index. Tools like "git mergetool" are then able to pull the competing versions out of the index to allow showing them at the same time.

My bias is that I've used VCSes before that wrote multiple competing files to the worktree and I have been happier with my experience resolving conflicts in git. E.g. at any step I can run a build to try out the current proposed resolution, and there's less of a chance of accidentally commiting a ~HEAD file.

[...]

Show 5 quoted lines

> There are three types of conflicts representing two (possibly
> unrelated) files colliding at the same path: add/add, rename/add, and
> rename/rename(2to1).  add/add does the two-way merge of the colliding
> files, and the other two conflict types write the two colliding files
> out to separate paths.

Interesting. I would be tempted to resolve this inconsistency the other way: by doing a half-hearted two-way merge (e.g. by picking one of the two versions of the colliding file) and marking the path as conflicted in the index. That way it's more similar to edit/edit, too.

Thanks, Jonathan