rebase vs rebase -i

rebase vs rebase -i

[Jay Soffian]

Why does git rebase use format-patch + am, while rebase -i uses cherry-pick?

Just curious. In particular though, it seems especially odd in this case:

$ git rebase --onto <newbase> <upstream>

vs

$ env GIT_EDITOR=true git rebase -i --onto <newbase> <upstream>

Both in theory produce an identical end-result, while using two
different implementations.

(Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
change the list of commits in the latter case.)

j.

Re: rebase vs rebase -i

[Johannes Schindelin]

Hi,

On Wed, 3 Feb 2010, Jay Soffian wrote:

> Why does git rebase use format-patch + am, while rebase -i uses 
> cherry-pick?

Hysterical raisins. 'rebase -i' started out as 'edit-patch-series.sh', 
hacked together in 4 hours on a lazy Saturday afternoon:
http://colabti.org/irclogger/irclogger_log/git?date=2007-02-27#l97

Ah, the old days. Back when I had enough time to read through Peff's 
mails. And back when I had enough time to cobble together fun Git scripts.

> Just curious. In particular though, it seems especially odd in this 
> case:
> 
> $ git rebase --onto <newbase> <upstream>
> 
> vs
> 
> $ env GIT_EDITOR=true git rebase -i --onto <newbase> <upstream>
> 
> Both in theory produce an identical end-result, while using two
> different implementations.
> 
> (Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
> change the list of commits in the latter case.)

You can get _exactly_ the same behavior if you use -m.

Ciao,
Dscho

Re: rebase vs rebase -i

[Jay Soffian]

On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> (Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
>> change the list of commits in the latter case.)
>
> You can get _exactly_ the same behavior if you use -m.

Or rather, -p. ;-)

j.

Re: rebase vs rebase -i

[Johannes Schindelin]

Hi,

On Thu, 4 Feb 2010, Jay Soffian wrote:

> On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >> (Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
> >> change the list of commits in the latter case.)
> >
> > You can get _exactly_ the same behavior if you use -m.
> 
> Or rather, -p. ;-)

No.  -p tries to preserve merges, and it will use 
git-rebase--interactive.sh for hysterical raisins.

I meant -m.

Ciao,
Dscho

Re: rebase vs rebase -i

[Jay Soffian]

On Thu, Feb 4, 2010 at 1:00 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 4 Feb 2010, Jay Soffian wrote:
>
>> On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> >> (Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
>> >> change the list of commits in the latter case.)
>> >
>> > You can get _exactly_ the same behavior if you use -m.
>>
>> Or rather, -p. ;-)
>
> No.  -p tries to preserve merges, and it will use
> git-rebase--interactive.sh for hysterical raisins.
>
> I meant -m.

I don't understand what you mean by "_exactly_ the same behavior" then.

"GIT_EDITOR=true git rebase -i" and "git rebase -p" both use
git-rebase--interactive.sh, and so are exactly the same behavior.

-m still uses git-rebase.sh, but calls merge instead of format-patch +
am. Perhaps the end-result is the same, but the behavior is different.

I guess I'm being a bit pedantic here, but I'm really just trying to
understand what you mean.

Thanks,

j.

Re: rebase vs rebase -i

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 807 bytes --]

Hi,

On Thu, 4 Feb 2010, Jay Soffian wrote:

> On Thu, Feb 4, 2010 at 1:00 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Thu, 4 Feb 2010, Jay Soffian wrote:
> >
> >> On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
> >> <Johannes.Schindelin@gmx.de> wrote:
> >> >> (Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
> >> >> change the list of commits in the latter case.)
> >> >
> >> > You can get _exactly_ the same behavior if you use -m.
> >>
> >> Or rather, -p. ;-)
> >
> > No.  -p tries to preserve merges, and it will use
> > git-rebase--interactive.sh for hysterical raisins.
> >
> > I meant -m.
> 
> I don't understand what you mean by "_exactly_ the same behavior" then.

Both "rebase -i" and "rebase -m" are really a cherry-pick in a loop.

Ciao,
Dscho

Re: rebase vs rebase -i

[Jay Soffian]

On Thu, Feb 4, 2010 at 1:46 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Both "rebase -i" and "rebase -m" are really a cherry-pick in a loop.

Well then I'm still confused. I see where pick_one() in
git-rebase--interactive.sh is using cherry-pick.

But call_merge() in git-rebase.sh is using git-merge-recursive (absent
specifying another strategy).

?

j.

Re: rebase vs rebase -i

[Junio C Hamano]

Jay Soffian <jaysoffian@gmail.com> writes:

> On Thu, Feb 4, 2010 at 1:46 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Both "rebase -i" and "rebase -m" are really a cherry-pick in a loop.
>
> Well then I'm still confused. I see where pick_one() in
> git-rebase--interactive.sh is using cherry-pick.
>
> But call_merge() in git-rebase.sh is using git-merge-recursive (absent
> specifying another strategy).
>
> ?

I think Dscho's point is that cherry-pick internally runs the same
merge-recursive.

When you have a change C based on its parent C^ and want to replay that
effect on a (possibly unrelated) commit A, you would run three-way merge,
merging C into A as if C^ is the common ancestor.  The rebase script
cherry-pick, and revert all work with the same principle (for revert
obviously you would swap C and C^---you are applying the effect of going
from C to C^ in that case).

And no, "format-patch --stdout | am -3" pipe in the normal rebase codepath
will stay unless you can produce a benchmark that says the performance of
merge machinery is good enough these days.  Back when "rebase -m" was
introduced, it wasn't.

Re: rebase vs rebase -i

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> And no, "format-patch --stdout | am -3" pipe in the normal rebase codepath
> will stay unless you can produce a benchmark that says the performance of
> merge machinery is good enough these days.  Back when "rebase -m" was
> introduced, it wasn't.

Just for fun, I pulled from the kernel tree.  Its tip is at fc76be4 (Merge
master.kernel.org:/home/rmk/linux-2.6-arm, 2010-02-04), which is a merge
of a subsystem tree into the mainline.

I tried to rebase HEAD^2 (i.e. subsystem change) on top of HEAD^1 (the
state Linus merged that subsystem change into).  Either way, the
experiment is to linearlize a side branch that has 16 patches:

The experiment is to take a history of this shape:

  --A-...--N--O--P master^2 = test (subsystem tip)
                  \
             ---X--Y master
          master^1

and turn it into a history of this shape:


  --A-...--N--O--P master^2 = test (subsystem tip)
                  \
             ---X--Y master
                 \
                  A'-B'-...O'-P' (rebased tip)

The tree at rebased tip P' must match the merge Y, of course.

First, to prepare:

    $ git checkout -b test master^2 ;# at the tip of subsystem
    $ git checkout HEAD^0 ;# detach so that I can easily repeat

Best of 5 runs on my box are:

    $ git reset --hard test && time git rebase master^1
    real    0m3.060s
    user    0m1.976s
    sys     0m0.812s

vs

    $ git reset --hard test && time git -m rebase master^1
    real    0m19.060s
    user    0m15.025s
    sys     0m3.564s

The numbers are understandable; the series touches only 12 paths among
31.5k paths, so applying patches has to be faster.

I have a plan to make a merge go faster by using a yet another merge
strategy, but that has been backburnered for now.

Re: rebase vs rebase -i

[Jay Soffian]

On Thu, Feb 4, 2010 at 7:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I think Dscho's point is that cherry-pick internally runs the same
> merge-recursive.

Ah hah, that's what I was missing. Thank you.

> When you have a change C based on its parent C^ and want to replay that
> effect on a (possibly unrelated) commit A, you would run three-way merge,
> merging C into A as if C^ is the common ancestor.  The rebase script
> cherry-pick, and revert all work with the same principle (for revert
> obviously you would swap C and C^---you are applying the effect of going
> from C to C^ in that case).
>
> And no, "format-patch --stdout | am -3" pipe in the normal rebase codepath
> will stay unless you can produce a benchmark that says the performance of
> merge machinery is good enough these days.  Back when "rebase -m" was
> introduced, it wasn't.

Indeed, the difference is painful on a largish tree (910M after gc
--aggressive, 39k files). Best of 3 runs for each of these:

$ time git rebase --onto HEAD~11 HEAD~10
First, rewinding head to replay your work on top of it...
[...]
real	0m11.164s
user	0m2.671s
sys	0m4.836s

$ time git rebase -m --onto HEAD~11 HEAD~10
[...]
real	0m40.507s
user	0m17.848s
sys	0m16.052s

$ time GIT_EDITOR="sed -i -e 1d" git rebase -i HEAD~11
[...]
real	0m27.758s
user	0m12.615s
sys	0m13.134s

It looks like there's room for improvement to rebase -m. (2.53 Ghz
Core 2 Duo Macbook Pro, 4GB memory.)

j.