Re: Git Merge 2020 slides and reproducibility

From: Elijah Newren <newren@gmail.com>
Date: Mar 7, 2020, 16:03 UTC
Message-ID: <CABPp-BECOarg+G-_oz83i0EuKuypJQA=wyjnfG4U0heG=0L0hg@mail.gmail.com>
In-Reply-To: <3165171583586403@sas1-2bf44b70450e.qloud-c.yandex.net>

On Sat, Mar 7, 2020 at 5:38 AM Konstantin Tokarev <annulen@yandex.ru> wrote:

Show 18 quoted lines

>
> 06.03.2020, 18:00, "Elijah Newren" <newren@gmail.com>:
> > Hi,
> >
> > Had a few different folks ask me at Git Merge about slides for my
> > talk. I said I'd post them on github somewhere, but in case you were
> > one of the folks and have a hard time finding it...they are up at
> > https://github.com/newren/presentations/blob/pdfs/merge-performance/merge-performance-slides.pdf
> > and steps to reproduce the speedups I got can be found at
> > https://github.com/newren/git/blob/git-merge-2020-demo/README.md
> > (though be forewarned that the code is has lots of fixmes & ifdefs &
> > other problems, has awful commit messages, etc.; I will be cleaning it
> > up soon).
>
> Hello, I've just tried your branch on my repository and it seems like it can
> be a salvation from all rename-related pain that I'm regularly facing when
> doing merges and cherry-picks! Thank you very much, I hope it will be
> integrated into mainline soon.

Wow, thanks for trying it out. Please note that while it _might_ be okay to use for real work, I am not that confident that it is. There are a number of factors making the 'demo' label I gave it a rather fitting one:

  * I only started using it personally on a real world repository (or
two) about a week and a half ago. (Before then, I knew merge-ort
didn't work.)
  * The second real world repo I used it on uncovered a bug in my code
that the testsuite didn't catch[1]
  * Although I've tested with two real world repos now, that testing
was very minimal; I was focused on getting the demo ready and
implementing as many optimizations as I could.
  * While the outer merge, rebase, and cherry-pick commands will
accept a bunch of merge-machinery options and pass them along,
merge-ort flat ignores them all.
  * merge-ort is hardcoded for merge.directoryRenames=true, when the
default should be merge.directoryRenames=conflict
  * it has a bunch of FIXMEs, some of which are code cleanliness
issues but some of which represent minor bugs

[1] https://lore.kernel.org/git/911de63afa274b0791e4d4252934a5e9b0031f10.1582762465.git.gitgitgadget@gmail.com/

Also...

Show 10 quoted lines

> However, when testing my previous merges which had to be done with helper
> script, I've encountered case of
>
> CONFLICT (directory rename split)
>
> Is there any way to prevent conflict in this case if files are the same, and
> merge their contents if there are differences? I think it would be reasonable
> to assume that move done in newest commit should win, and allow user
> to change strategy via command line option, provide explicit hint where files
> should be moved, or maybe even decide it interactively.

This conflict message is known to trigger in some cases where it shouldn't; it may be that you're just experiencing annoyance from that. Let me fix that issue before worrying about workarounds.

Also, if you try out the 'fast-rebase' builtin from that branch (which is a demo only and not meant to become a real command), note that its usage message is really helpful: $ git fast-rebase -h fatal: usage: read the code, figure out how to use it, then do so

It's the kind of thing you put in code when you're trying to get it working the night before you'll include its results in your talk (and finish getting it to work the morning of)...

Anyway, thank you very much for giving it a whirl and reporting, just please be cautious about depending on it since it's still work in progress.

Elijah