Re: Opinions on changing add/add conflict resolution?

From: Elijah Newren <newren@gmail.com>
Date: Mar 13, 2018, 17:09 UTC
Message-ID: <CABPp-BEOi6GAoHUZyfcJdd-eLwPLoyRMOiS-J1dvkjqm7VGj9Q@mail.gmail.com>
In-Reply-To: <871sgoqos3.fsf@evledraar.gmail.com>

On Tue, Mar 13, 2018 at 2:59 AM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

> On Tue, Mar 13 2018, Elijah Newren jotted:

Show 16 quoted lines

>> However, I'm far more concerned with the three collision conflict types
>> having consistent behavior than I am with changing add/add conflict
>> handling.  And if your two concerns or Jonathan's concern would prevent you
>> from wanting to use the new merge strategy (and possibly prevent it from
>> becoming the default in the future), I'd much rather just modify rename/add
>> and rename/rename to behave like add/add.  Would that be more to your
>> liking?
>
> I don't really object to these changes, I don't know enough about this
> area, I skimmed your patches and 90% of it is over my head (although I
> could keep digging...).
>
> I'm just chiming in because it seems to me from upthread that you're
> purely focusing on the use-case of the user of git who's using git at
> the abstraction of using a dumb editor that doesn't do anything to help
> them with conflict markers to resolve conflicts.

Yeah, that's totally why I started this separate thread; I was worried the original would push away folks who weren't familiar enough with merge-recursive or were just overwhelmed by all the different changes and rationale, but I really wanted to get feedback on at least the piece that people were likely to hit in practice and would understand. Thanks for doing so; your, and Jonathan's, and Junio's comments have provided some good context.

> Also another caveat: Since these are new side-files what happens when
> you're in a conflict and run `git clean -dxf`, are these new files wiped
> away, or are they somehow known to the index?

A git clean would wipe them out...and if that scares you (and I can totally see how it might), then rest assured that the situation is a whole lot worse: this isn't limited to rename/add and rename/rename(2to1) conflicts. There are several paths in merge-recursive.c that call unique_path() to get a temporary filename that is in no way tracked in the index but which is used for storing content relevant to the merge. These include directory/file conflicts, untracked files being in the way of putting a renamed file where it belongs, untracked files being in the way of a modify/delete, untracked files being in the way of simple adds on the other side of history, rename/rename(1to2)/add/add, and maybe others. In all cases, a git clean is going to wipe out the files that were written to different temporary locations.

My rewrite I'm trying to find time to work on would get rid of the code paths involving untracked files being in the way of other stuff, but would do nothing for the other cases. I would love to get rid of all of them, but don't have a clue how to do so.