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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 17, 2023, 13:21 UTC
Message-ID: <304f2a49-5e05-7655-9f87-2011606df5db@gmx.de>
In-Reply-To: <CABPp-BE5h6C1iuGDz4HdJzb2bDLidEnQ0_U4fv93JrYXA2_cbw@mail.gmail.com>

Hi,

On Mon, 7 Aug 2023, Elijah Newren wrote:

Show 30 quoted lines

> 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.

Show 9 quoted lines

> 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.

Show 8 quoted lines

> 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