Re: [PATCH v3 2/3] merge: Add merge.renames config setting

From: Elijah Newren <newren@gmail.com>
Date: Apr 27, 2018, 20:23 UTC
Message-ID: <CABPp-BHwM1jx2+VTxt7hga7v-E6gvHuxVNPqm-MPRXYe5CDVtA@mail.gmail.com>
In-Reply-To: <20180427183752.GA2799@esm>

On Fri, Apr 27, 2018 at 11:37 AM, Eckhard Maaß <eckhard.s.maass@googlemail.com> wrote:

Show 10 quoted lines

> On Fri, Apr 27, 2018 at 11:23:56AM +0900, Junio C Hamano wrote:
>> I think demoting from copy to rename-only is a good idea, at least
>> for now, because I do not believe we have figured out what we want
>> to happen when we detect copied files are involved in a merge.
>
> Does anyone know some threads concerning that topic? I tried to search
> for it, but somehow "merge copy detection" did not find me useful
> threads so far. I would be interested in that topic anyway, so I would
> like to know what the ideas are that floated so far.
>

I doubt it has ever been discussed before this thread.  But, if you're
curious, I'll try to dump a few thoughts.  Let's say we have branches
A and B, and:
   A: modifies file z
   B: copies z to y

Should the modifications to z done in A propagate to both z and y? If not, what good is copy detection? If so, then there are several ramifications...

- If B not only copied z but also first modified it, then do we have
  potential conflicts with both z and y -- possibly the exact same
  conflicts, making the user resolve them repeatedly?

- What if A copied z to x?  Do changes to z propagate to all three of
  z and x and y?  Do changes to either x or y affect z?  Do they
  affect each other?

- If A deleted z, does that give us a copy/delete conflict for y?  Do
  we also have to worry about copy/add conflicts?  copy/add/delete?
  rename/copy (multiple variants)?  copy/copy?

- Extra degrees of freedom may mean new conflict types:

  - The extra degrees of freedom from renames introduced multiple new
    conflict types (e.g. rename/add, rename/rename(1to2),
    rename/rename(2to1)).

  - Directory rename detection added more (rename/rename/rename(1to3),
    rename/rename(Nto1), add/add/add, directory/file/file, n-fold
    transitive rename, etc.), -- and forced us to specify various
    rules to limit the possibility space so that conflicts could be
    representable in the index and understandable by the user.

  - I suspect adding copies would add new types of conflicts we
    haven't thought of yet.

The more I think about it, the more I think that attempting to detect copies in a merge algorithm just doesn't make sense. Anything I can think of that someone might attempt to use detected copies for would just surprise users in a bad way...and it'd open up a big can of edge and corner case problems as well.