Re: [RFC] introducing git replay
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Apr 13, 2022, 19:07 UTC
- Message-ID
- <220413.86o814er20.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <CAOc6etbheKZ9CYJ+6Chz9gDj1WGK_5hQeHYTmhOKiUtDd0RKtQ@mail.gmail.com>
On Wed, Apr 13 2022, Edmundo Carmona Antoranz wrote:
Show 17 quoted lines
> On Wed, Apr 13, 2022 at 7:45 PM Phillip Susi <phill@thesusis.net> wrote: >> >> >> Edmundo Carmona Antoranz <eantoranz@gmail.com> writes: >> >> > If HEAD and v2.35.0 share the same tree, it _should_ be possible >> > to recreate the commits that make up the range v2.35.0..v2.36.0-rc1 >> > on top of HEAD without requiring any real "rebasing". Just creating >> >> Isn't that literally the definition of rebase? >> > > Well, yeah. :-) What I mean is to skip the rebase _engine_. No > merging/cherry-picking/conflicts along the way of recreating the > new revisions. Say, clone the exact same revisions that we want to > _rebase_ and adjust their parents, nothing else (or little else, like adjusting > the committer).
Yeah I think this is fundimentally a good idea to pursue, and it's been discussed at various times in the past, and indeed, it seems best to pursue it as a rebase optimization.
I.e. given a history that has say files A.txt and B.txt, and a fork from A adding X.txt and Y.txt (and nothing else) we should be able to do a "light rebase" in moving that X & Y forward to it has B as the parent.
Right now we do a rebase in all its glory to do that, with index updating along the way (I forget how much that's been optimized, if at all) etc.
But if we can detect that we say only have additions of new files we could just munge the headers as we go along, and the rest should all be happening essentially as fast as we can SHA-1 the commit objects, which is basically what this built-in does, right?