Re: [PATCH v3 11/33] directory rename detection: testcases exploring possibly suboptimal merges
- From
Stefan Beller <sbeller@google.com>
- Date
- Nov 22, 2017, 18:29 UTC
- Message-ID
- <CAGZ79kbMuxnToLazoVh6sx5ujB2Hh+eUqVy9j3dN6MnnJiZ-qQ@mail.gmail.com>
- In-Reply-To
- <20171121080059.32304-12-newren@gmail.com>
> +# Note: Both x and y got renamed and it'd be nice to detect both, and we do > +# better with directory rename detection than git did previously, but the > +# simple rule from section 5 prevents me from handling this as optimally as > +# we potentially could.
...previously...
Show 7 quoted lines
> +# Testcase 8e, Both sides rename, one side adds to original directory
> +# Commit O: z/{b,c}
> +# Commit A: y/{b,c}
> +# Commit B: w/{b,c}, z/d
> +#
> +# Possible Resolutions:
> +# Previous git: z/d, CONFLICT(z/b -> y/b vs. w/b), CONFLICT(z/c -> y/c vs. w/c)"Previous git" may be hard to understand when reviewing this code in 2 years. The future proof term is "git without dir rename detection" or such. (This is only a small nit, which on its own doesn't require a reroll; I'll keep reading.)