Edmundo Carmona Antoranz <eantoranz@xxxxxxxxx> writes:
> builtin/rebase.c | 230 ++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 229 insertions(+), 1 deletion(-)
Hmph, somebody other than myself would have a nice thing to say
about this. I have a feeling that this case is too narrow to be
worth adding 230 lines, if it requires end-user intervention.
Without any additional end-user input like "--recycle", is it
possible to dynamically and cheaply tell if the recycle mechanism
can be silently and transparently usable as a more efficient
alternative that would produce exactly the same result as the normal
rebase mechanism? Using
(1) the range being rebased,
(2) the tree of the "onto" commit, and
(3) the desired shape of the resulting history
as input, wouldn't you be able to tell? IOW, with
$ git rebase --onto=A B C
if there is no clear bottom of the range being rebased (i.e. "git
merge-base B C" may have multiple commits), or if the bottom of the
range being rebased has a tree different from that of commit A, then
we know "recycle" would not work even without trying.
Also, when the range B..C is not a single strand of pearls and we
ended up choosing REBASE_APPLY due to what the command line or
configration variable said, we cannot use recycle even if the tree
of the bottom of the range matches the tree of A, because
REBASE_APPLY wants to lineralize the history, while recycle
mechinery is about replanting the whole bush structure verbatim, so
it is a bad match.
But when (i) there is a clear single bottom of the range B..C (let's
call that X), and (ii) the tree of that bottom matches the tree of A
(i.e. X^{tree} == A^{tree}) and (iii) either we are asked to do
REBASE_MERGE or the history being rebased B..C is linear, then
B
/
o---X---M---N---Q---C
\ \ /
\ O---P
\
A
we should be able to exercise the recycle engine _without_ even
telling the user that we did, and the only visible effect to the
end-user and to the resulting history is that we (hopefully) did a
better job with smaller amount of CPU cycles, no?
B
/
o---X
\
\
\
A---M'--N'--Q'--C
\ /
O'--P'
Without thinking too much about it, I do not think there is any case
where you cannot tell mechanically that recycle would be usable as a
pure optimization. And if that is the case, forcing end-user to say
"try recycle, it might work, and otherwise fall-back" does not help
anybody. If it is automatable easily, we should spend extra brain
cycles to automate it and not bother the users.
That way, you do not even need to add a single line of
documentation, even though you still need to have tests.
> This is the rebase-based implementation of my original
> git replay concept.
>
> Decided to change the name to "recycle" because there is already
> code that relates to "replay" in rebase... and we are "recycling"
> trees so the name sounds appropriate (but might consider other
> proposals if they gather steam).
I saw "recycle commit" in the code, but you are indeed recycling
trees. But I prefer to see us think it through---I have this
feeling that we do not have to expose any of the candidate words
recycle, replay, replant, ... to end users and just use the new code
as a special codepath that does not call out to the true merge
engine.
> There are things that are missing like documentation
> and I will gladly add them (along with correcting anything
> coming from code review) if this feature is interesting enough
> for inclusion in the main line.
The last thing I want to hear from contributors in the open source
development setting: I'll polish it more if you promise this will be
included.
If it is NOT even interesting and useful enough to make you want to
polish and perfect it, even when you were the only user, why should
we be interested? Even if your userbase starts at zero (or one,
counting yourself), if you make it so good, other people will come
to you, begging you to add that to the public tool.
