Hi Stefan, On Tue, May 29, 2018 at 3:12 PM, Stefan Beller <sbeller@xxxxxxxxxx> 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@xxxxxxxxxxxxx/ > (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@xxxxxxxxxxxxxx/ 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > Did you mean: > https://public-inbox.org/git/xmqqd147kpdm.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ 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
