On Fri, Apr 27, 2018 at 11:37 AM, Eckhard Maaß
<eckhard.s.maass@xxxxxxxxxxxxxx> wrote:
> 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.
