Re: [RFC] introducing git replay

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Apr 13 2022, Edmundo Carmona Antoranz wrote:

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