rebase vs rebase -i

7 messages, 2 authors, 2016-06-15 · open the first message on its own page

rebase vs rebase -i

From: Jay Soffian <hidden>
Date: 2016-06-15 22:48:10

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

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:48:10

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

From: Jay Soffian <hidden>
Date: 2016-06-15 22:48:10

On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
[off-list ref] wrote:
quoted
(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

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:48:10

Hi,

On Thu, 4 Feb 2010, Jay Soffian wrote:
On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
[off-list ref] wrote:
quoted
quoted
(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

From: Jay Soffian <hidden>
Date: 2016-06-15 22:48:10

On Thu, Feb 4, 2010 at 1:00 PM, Johannes Schindelin
[off-list ref] wrote:
Hi,

On Thu, 4 Feb 2010, Jay Soffian wrote:
quoted
On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
[off-list ref] wrote:
quoted
quoted
(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

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:48:10

Hi,

On Thu, 4 Feb 2010, Jay Soffian wrote:
On Thu, Feb 4, 2010 at 1:00 PM, Johannes Schindelin
[off-list ref] wrote:
quoted
On Thu, 4 Feb 2010, Jay Soffian wrote:
quoted
On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
[off-list ref] wrote:
quoted
quoted
(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

From: Jay Soffian <hidden>
Date: 2016-06-15 22:48:10

On Thu, Feb 4, 2010 at 1:46 PM, Johannes Schindelin
[off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help