Re: Some ideas for StGIT

["Shawn O. Pearce" <spearce@spearce.org>]

Jakub Narebski <jnareb@gmail.com> wrote:
> Shawn O. Pearce wrote:
> 
> > (Regarding the performance, cherry-picking 55 patches is
> > slow, especially when many of them would apply trivially with
> > git-diff|git-apply --index.  Be nice to improve that in 1.5.4.)
> 
> Perhaps in the future you would be able to use -i/--interactive mode
> in merge driven git-rebase (git rebase --merge -i <base>), which I think
> should be faster.

Heh.  You're talking to someone who actually knows what he is talking
about here, and was actually involved in some of these tools...
Let me fill the reader in on what's really happening...

`git-rebase` (non -i, non -m) uses `format-patch|am` to apply the
changes of each commit it is rebasing.  This is insanely fast as
builtin diff and apply routines are quite efficient.  It sometimes
fails due to patches not applying cleanly.  In those cases you
have to either hand edit the patch, apply and continue the rebase,
or abort the rebase and restart with the -m flag so it uses a full
three-way file merge.

`git-rebase -m` (aka --merge) uses git-merge-recursive to apply the
changes of each commit it is rebasing.  (That's the merge part!)
However merge-recursive usually takes longer to run then the above
`format-patch|am` pipeline, and that is why -m is not the default.
But it does handle cases `format-patch|am` cannot do automatically.

For quite a long time now both `git-revert` and `git-cherry-pick`
(which are actually the same program!) have also been using
git-merge-recursive as their implementation to revert or apply the
commit's change.  This allows them to perform changes that also
involve renames, as well as to apply some changes that might fail
as a patch but succeed when done as a three-way file merge.

So really `revert`, `cherry-pick`, `rebase -m` (and also `am -3`
as it also uses merge-recursive) are all the same underlying
implementation.  The major differences between them is what they
do *after* the changes have been applied, and which direction the
change goes (e.g. revert undoes the change).

Now the new `git-rebase -i` is really just a complicated loop around
`cherry-pick`.  Really.  Go look at the code, it never calls anything
except cherry-pick.  So `rebase -i` is actually `rebase --merge -i`.
That's why its sluggish.

Why is merge-recursive sluggish?  It does rename detection.
It does full three-way file merges, rather than just applying
a patch.  It also tries to do a three-way read-tree before doing
file level merges.  git-apply does none of these things, and is
faster because of it.

So that future you speak of above is today.  Its also not faster,
its slower.  Faster would be to do something like `format-patch|am -3`
so that merge-recursive is only invoked if git-apply was unable to
apply the patch automatically.  Except we'd want to save the original
tree data so we can do proper rename detection when merge-recursive
is fired up.

-- 
Shawn.