Re: RFC: Merge-related plans

On Mon, May 28, 2018 at 1:48 PM, Elijah Newren [off-list ref] wrote:

Hi everyone,

I have some merge-related plans (and work in progress) that I'd like
to get some feedback on in order to find what order would be best to
address things in, if there are special steps I should take while
approaching some of the bigger items, and even if folks disagree with
any of the plans.


Currently, I would like to:

A) Fix cases where directory rename detection does not work with
   rebase/am due to how they call merge-recursive.

   Notes: Could just wait for D & E to land before fixing.
   Alternatively, email RFC to list now explaining issues and how the
   fix has performance implications; poll for opinions on whether to
   fix before or after D.

B) Implement a remerge-diff ability (compare a merge commit to what an
   "automatic merge" would look like)[1].

   Notes: Possibly for cherry-picks and reverts too.  Depends on C &
   E.

C) Modify/extend how path-based and mode-based conflicts are
   communicated to the user.

   Notes: Particularly important as a mechanism for handling
   challenges[2] with implementing the remerge-diff ability.  Need to
   send RFC to list with ideas to get feedback.

D) Improve merge performance.

   Notes: Includes 4-5 specific optimizations[5], some of which I
   expect to be somewhat invasive and thus may make more sense to just
   make part of the new merge strategy implemented in E.  Biggest
   optimization depends on F.

E) Write a new merge strategy meant to replace merge-recursive.

   Notes: Suggested by Junio[3][4].  Depends on F & G.

F) Make file collision conflict types more consistent.

   Notes: Specifically, make rename/rename(2to1) & rename/add
   conflicts behave more like add/add[6][7].  Depends on part of G.
   Would prefer H to be accepted first.

G) Improve merge-related portion of testsuite.

   Notes: Intended to help test new merge strategy with more
   confidence.  Will include approximately a dozen edge and corner
   cases where merge-recursive currently falls short.  Started at [8];
   see also [9].

Most items forward-reference "Depends on (<later letter>) up to here;
(H) seems independent, but might be a good first start.
(G) [8] is queued as origin/en/merge-recursive-tests, or do you mean
to expand (G) into a mini-framework of merge-testing? i.e. run the
mini test framework multiple times, each using a different
merge strategy, similar to submodule tests, e.g. see
t/lib-submodule-update.sh and one of its users, t1013.

H) Miscellaneous code cleanups irritating me while working on other
   changes[10].


My current plan was to work roughly in reverse, from H to A.  Some questions:

  * Does any of this look objectionable?

Going in order A-H seems slightly out-of-order to me, I'd think (H) and (G)
would go first;

(B) sounds like an independent feature, which could go in parallel?

  * Should I post RFC questions on A and C earlier?

I would think so, it is easier to give feedback on code, I would think.

  * Should I split D and G?  (Current plan was to keep D together, but
    split G into five short slightly inter-dependent topics)

I would have expected to have tests (G) as a companion of (A) or (C)
rather than (D), as performance improvements would keep the test suite
unchanged?

  * E is kind of big.  Are there any specific things folks would like to see
    with how that is handled?

How much abstraction can be done ahead of time such that there is an
interface/API where you just plug in a new merge strategy and do not
need to duplicate a lot of code/tests?

Stefan