Hi again,
Elijah Newren wrote:
> On Mon, Mar 12, 2018 at 11:47 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
>> 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.
[...]
>> 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.
> 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.
[...]
> 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
