Re: RFC: Merge-related plans

[Elijah Newren <newren@gmail.com>]

Hi Stefan,

On Tue, May 29, 2018 at 3:12 PM, Stefan Beller <sbeller@google.com> wrote:
>>> (B) sounds like an independent feature, which could go in parallel?
>>
>> B may sound like an independent feature, but it needs a merge
>> algorithm that doesn't mess with the working tree
>
> I agree on that,
>
>> so it depends pretty strongly on E.
>
> .. but not quite on the conclusion:
> You could also make the current merge algorithm working
> tree independent. Thomas Rast (cc'd) did so IIUC in
> https://public-inbox.org/git/cover.1409860234.git.tr@thomasrast.ch/
> (search the archive for "--remerge" if interested in this prior work)
> which did not land upstream.

I'm aware of Thomas' remerge-diff series (it's where I got the name
from, and I linked to it in
https://bugs.chromium.org/p/git/issues/detail?id=12).  It's some
pretty cool work.  I also submitted a previous series to make
merge-recursive not touch the working tree (for different reasons),
and then when folks pointed out the similarity between my series and
Thomas' in this area, I compared our approaches:

https://public-inbox.org/git/CABPp-BG49Gr3Kf8Q3E6Vc=GF9MG+m10HkhkwbaOBfzs1cFcgVw@mail.gmail.com/

I still think my approach to the do-not-touch-worktree aspect was
cleaner, but both complicate the already excessively complex
merge-recursive codebase, and just dance around the fundamental design
flaw in merge-recursive (discussed more at the end of the email via
links to Junio's thoughts on the topic).  At this point, I'd rather
just fix the design flaw rather than complicate the code further.

>> If the idea is to give feedback on *code* rather than just
>> ideas/tradeoffs/pinpointing-buggy-lines, then it sounds like you're
>> actually suggesting posting the RFC later rather than earlier?
>
> Some people have complained that they don't get feedback on
> ideas/tradeoffs/pinpointing-buggy-lines, but did so after sending
> RFC code. So I'd think a sure way to get feedback is to send actual
> code as an RFC even if it misses some parts.

Makes sense.

>> Also, the bigger question for me wasn't so much "should I ask the list
>> about these changes?" before making them, but rather: Do folks want me
>> to bring these things up before I work on D & E -- even if I end up
>> not getting back to incorporating their answers for months until D & E
>> are completed and merged?
>
> I'd think A + C are worth asking early nevertheless, even if D & E are
> away for some month; having these niche cases covered (in code and
> tests) as well as a new UI/UX for user communication sound exciting
> (The latter could result in some bike shedding, and then having enough
> time before you spend time to do it one way or another in D&E sounds
> favorable)

Okay, sounds like I need to put a little code behind my ideas, at
least enough for some RFCs.

> My experience is that smaller patch series are reviewed faster,
> so if the cost of splitting them up is not prohibitive, I'd strongly
> consider doing that.

Will do.

> So your long term plan is to *replace* the whole merge recursive strategy
> giving the same results.

Yes, precisely.  :-)

>> For avoiding duplicate code...well, Junio's suggestion was "[to
>> rewrite] without using much from the existing code in
>> merge-recursive.c at all" because he has "written off that code as
>> mostly unsalvageable"[4].
>
>>>> [4] https://public-inbox.org/git/xmqqk1ydkbx0.fsf@gitster.mtv.corp.google.com/
>
> Did you mean:
> https://public-inbox.org/git/xmqqd147kpdm.fsf@gitster.mtv.corp.google.com/

The email you link describes the new algorithm behind the replacement
strategy.  That's a useful email, but I was specifically trying to
reference where I was quoting Junio from, which was the email where
Junio suggested implementing the new algorithm as a replacement
strategy rather than re-factoring merge-recursive.c; those quotes came
from the email link I gave.

> So in that case my reply above ("..so it depends pretty strongly on E.."
> I have a different conclusion) is void, as that *is* the new strategy?

Yes, I think Junio's suggestion is a _much_ cleaner way of getting a
do-not-touch-the-working-tree merge than either Thomas' or my previous
submissions. It's a much, much bigger chunk of work to do it that way,
but will fix multiple other problems that the current design make hard
or impossible to fix.


Thanks for the feedback!
Elijah