Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]

Hi,

On Mon, 7 Aug 2023, Elijah Newren wrote:

> On Mon, Aug 7, 2023 at 9:19 AM Junio C Hamano <gitster@pobox.com> wrote:
> >
> [...]
> > >> However in a recent article
> > >> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)
> > >> GitHub says that they are already using git-replay (though not sure
> > >> it's this exact version or another one), and GitLab plans to use it
> > >> too.
> >
> > So there are plenty folks who are capable of reviewing but they are
> > not interested in giving it to the general public by withholding
> > their reviews ;-)?
>
> I can see how one could jump to that conclusion, but I don't think
> it's warranted.  I have a little information that might shed some
> light:
>
> -----
>
> At the beginning of July, well before the above link came out,
> Johannes sent me an email pointing me at
> https://github.blog/changelog/2023-06-28-rebase-commits-now-created-using-the-merge-ort-strategy/.
> In the email, he also noted my earlier stated concerns on the list
> (about releasing `replay` early possibly painting us into a corner
> preventing some desired goals for the tool from being realized), and
> tried to ensure we could still work towards having a `replay` command
> like the one I envisioned while also asking for my thoughts on pushing
> for the current portion of work to be published and included in git.
> My sense was he was pushing for the work to be released, but just
> being careful about my concerns first.

Indeed. The patches that are running on GitHub to support rebases
incorporate v3 of the `git-replay` patch series, and add a couple of
patches on top to perform rebases similar to how things were done using
libgit2 before.

> Unfortunately, I was on vacation that week, and sadly have otherwise
> been buried in coming up to speed on a new team and haven't had time
> to even respond to git-related stuff.  I didn't respond to him until
> late last week.
>
> I pointed out that the 'EXPERIMENTAL' banner addresses most of my
> concerns so it should be fine to move forward, but I suspect my delay
> has resulted in him now being buried in other matters, and in the
> mean-time the article Christian highlighted was produced by others.

The article was produced with my input, so I cannot claim innocence.

The reason why I did not respond earlier is that I wanted to have more
time to push forward with your vision of `git replay`, in a direction
where it avoids repeating the design of `git rebase`.

About integrating the current patch series as-is, I would be fine with it.
The best support I can offer is that this code (with minor changes that do
not fundamentally modify how the core logic works) has performed
gazillions of rebases in the meantime.

We just need to be mindful to keep that EXPERIMENTAL label until we fully
implement the design Elijah envisions. Which might very well need the user
interface to change rather drastically.

> Anyway, hope that helps.  I did review V2 and have been meaning to
> comment on V3 (and respond to Toon's comments), though not sure my
> "review" counts as such since I'm the original author of most of the
> patches...
>
> (And sorry for being missing in action.  I've flagged a few other
> emails that I'm hoping I can follow up on, but my time is currently
> quite limited...)

I haven't been a frequent guest on the Git mailing list, either, lately...

Ciao,
Johannes