git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
* git rebase: retain original head?
@ 2019-01-08 15:06 Markus Wiederkehr
  2019-01-08 17:43 ` Andreas Schwab
  0 siblings, 1 reply; 9+ messages in thread
From: Markus Wiederkehr @ 2019-01-08 15:06 UTC (permalink / raw)
  To: git

Hello,

I frequently run an interactive rebase to change the order of recent
commits, apply fixups, etc. When merge conflicts occur I often want to
compare the result with the original head prior to starting the
rebase.

In the past I used "git diff ORIG_HEAD". This used to work as long as
I did not manually invoke "git reset" during the operation.

Since git version 2.20.1 (not sure, maybe 2.20.0?) this no longer
works because ORIG_HEAD seems to get modified by fixup commits during
rebase. Now I have to search through reflog to find the commit I want
to compare the current head to.

During the rebase operation the original head seems to get stored in
'rebase-merge/orig-head'. Unfortunately this references gets removed
after the rebase operation completes.

Would it be possible to retain this information? Could you set
ORIG_HEAD back to rebase-merge/orig-head after rebase completes?
Alternatively, could something like REBASE_HEAD be added for this
purpose?

Undoing a rebase would be related to this and is a very popular
question on SO [1]. Users recommend using "git reset --hard ORIG_HEAD"
which now no longer works.

Regards,
Markus

[1] https://stackoverflow.com/questions/134882

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: git rebase: retain original head?
  2019-01-08 15:06 git rebase: retain original head? Markus Wiederkehr
@ 2019-01-08 17:43 ` Andreas Schwab
  2019-01-08 20:38   ` Markus Wiederkehr
  0 siblings, 1 reply; 9+ messages in thread
From: Andreas Schwab @ 2019-01-08 17:43 UTC (permalink / raw)
  To: Markus Wiederkehr; +Cc: git

On Jan 08 2019, Markus Wiederkehr <markus.wiederkehr@gmail.com> wrote:

> During the rebase operation the original head seems to get stored in
> 'rebase-merge/orig-head'. Unfortunately this references gets removed
> after the rebase operation completes.
>
> Would it be possible to retain this information?

You could use the reflog of the current branch, where it is the second
entry.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: git rebase: retain original head?
  2019-01-08 17:43 ` Andreas Schwab
@ 2019-01-08 20:38   ` Markus Wiederkehr
  2019-01-08 20:51     ` Andreas Schwab
  2019-01-08 21:22     ` Jacob Keller
  0 siblings, 2 replies; 9+ messages in thread
From: Markus Wiederkehr @ 2019-01-08 20:38 UTC (permalink / raw)
  To: git

On Tue, Jan 8, 2019 at 6:43 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Jan 08 2019, Markus Wiederkehr <markus.wiederkehr@gmail.com> wrote:
>
> > Would it be possible to retain this information?
>
> You could use the reflog of the current branch, where it is the second
> entry.

It is not, depending on what happens in the rebase it could be any
entry. That's why I always have to search for the right one, which is
tedious.

Example:

$ git rebase -i root-tag
... (apply one fixup)
$ git reflog
906caf1c (HEAD -> master) HEAD@{0}: rebase -i (finish): returning to
refs/heads/master
4906caf1c (HEAD -> master) HEAD@{1}: rebase -i (pick): qux
85dab37b4 HEAD@{2}: rebase -i (pick): baz
7de7420d2 HEAD@{3}: rebase -i (fixup): bar
9bc0461c0 HEAD@{4}: rebase -i (start): checkout root-tag
a150b73ca HEAD@{5}: commit: foo

Here I have to use HEAD@{5}.

Markus

On Tue, Jan 8, 2019 at 6:43 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Jan 08 2019, Markus Wiederkehr <markus.wiederkehr@gmail.com> wrote:
>
> > During the rebase operation the original head seems to get stored in
> > 'rebase-merge/orig-head'. Unfortunately this references gets removed
> > after the rebase operation completes.
> >
> > Would it be possible to retain this information?
>
> You could use the reflog of the current branch, where it is the second
> entry.
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: git rebase: retain original head?
  2019-01-08 20:38   ` Markus Wiederkehr
@ 2019-01-08 20:51     ` Andreas Schwab
  2019-01-09 13:48       ` Markus Wiederkehr
  2019-01-08 21:22     ` Jacob Keller
  1 sibling, 1 reply; 9+ messages in thread
From: Andreas Schwab @ 2019-01-08 20:51 UTC (permalink / raw)
  To: Markus Wiederkehr; +Cc: git

On Jan 08 2019, Markus Wiederkehr <markus.wiederkehr@gmail.com> wrote:

> On Tue, Jan 8, 2019 at 6:43 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>>
>> On Jan 08 2019, Markus Wiederkehr <markus.wiederkehr@gmail.com> wrote:
>>
>> > Would it be possible to retain this information?
>>
>> You could use the reflog of the current branch, where it is the second
>> entry.
>
> It is not, depending on what happens in the rebase it could be any
> entry.

Don't look at the HEAD reflog, use the branch reflog, ie. @{1}.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: git rebase: retain original head?
  2019-01-08 20:38   ` Markus Wiederkehr
  2019-01-08 20:51     ` Andreas Schwab
@ 2019-01-08 21:22     ` Jacob Keller
  2019-01-09 14:05       ` Johannes Schindelin
  1 sibling, 1 reply; 9+ messages in thread
From: Jacob Keller @ 2019-01-08 21:22 UTC (permalink / raw)
  To: Markus Wiederkehr; +Cc: Git mailing list

On Tue, Jan 8, 2019 at 12:47 PM Markus Wiederkehr
<markus.wiederkehr@gmail.com> wrote:
>
> On Tue, Jan 8, 2019 at 6:43 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> >
> > On Jan 08 2019, Markus Wiederkehr <markus.wiederkehr@gmail.com> wrote:
> >
> > > Would it be possible to retain this information?
> >
> > You could use the reflog of the current branch, where it is the second
> > entry.
>
> It is not, depending on what happens in the rebase it could be any
> entry. That's why I always have to search for the right one, which is
> tedious.
>
> Example:
>
> $ git rebase -i root-tag
> ... (apply one fixup)
> $ git reflog
> 906caf1c (HEAD -> master) HEAD@{0}: rebase -i (finish): returning to
> refs/heads/master
> 4906caf1c (HEAD -> master) HEAD@{1}: rebase -i (pick): qux
> 85dab37b4 HEAD@{2}: rebase -i (pick): baz
> 7de7420d2 HEAD@{3}: rebase -i (fixup): bar
> 9bc0461c0 HEAD@{4}: rebase -i (start): checkout root-tag
> a150b73ca HEAD@{5}: commit: foo
>
> Here I have to use HEAD@{5}.
>

He meant using:

$ git reflog master

which only shows changes directly to the master ref, not to HEAD.
During a git rebase operations don't modify the master ref until after
the rebase finishes. This, of course, assumes you're on a branch.

If so, you should even be able to use master@{1} and be safe in
assuming it always refers to what the branch was before the rebase
started.

Thanks,
Jake

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: git rebase: retain original head?
  2019-01-08 20:51     ` Andreas Schwab
@ 2019-01-09 13:48       ` Markus Wiederkehr
  0 siblings, 0 replies; 9+ messages in thread
From: Markus Wiederkehr @ 2019-01-09 13:48 UTC (permalink / raw)
  To: git

On Tue, Jan 8, 2019 at 10:29 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Jan 08 2019, Markus Wiederkehr <markus.wiederkehr@gmail.com> wrote:
>
> > It is not, depending on what happens in the rebase it could be any
> > entry.
>
> Don't look at the HEAD reflog, use the branch reflog, ie. @{1}.

That's exactly what I was looking for, thanks!

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: git rebase: retain original head?
  2019-01-08 21:22     ` Jacob Keller
@ 2019-01-09 14:05       ` Johannes Schindelin
  2019-01-09 15:08         ` Markus Wiederkehr
  0 siblings, 1 reply; 9+ messages in thread
From: Johannes Schindelin @ 2019-01-09 14:05 UTC (permalink / raw)
  To: Jacob Keller; +Cc: Markus Wiederkehr, Git mailing list

Hi Jake,

On Tue, 8 Jan 2019, Jacob Keller wrote:

> On Tue, Jan 8, 2019 at 12:47 PM Markus Wiederkehr
> <markus.wiederkehr@gmail.com> wrote:
> >
> > On Tue, Jan 8, 2019 at 6:43 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> > >
> > > On Jan 08 2019, Markus Wiederkehr <markus.wiederkehr@gmail.com> wrote:
> > >
> > > > Would it be possible to retain this information?
> > >
> > > You could use the reflog of the current branch, where it is the second
> > > entry.
> >
> > It is not, depending on what happens in the rebase it could be any
> > entry. That's why I always have to search for the right one, which is
> > tedious.
> >
> > Example:
> >
> > $ git rebase -i root-tag
> > ... (apply one fixup)
> > $ git reflog
> > 906caf1c (HEAD -> master) HEAD@{0}: rebase -i (finish): returning to
> > refs/heads/master
> > 4906caf1c (HEAD -> master) HEAD@{1}: rebase -i (pick): qux
> > 85dab37b4 HEAD@{2}: rebase -i (pick): baz
> > 7de7420d2 HEAD@{3}: rebase -i (fixup): bar
> > 9bc0461c0 HEAD@{4}: rebase -i (start): checkout root-tag
> > a150b73ca HEAD@{5}: commit: foo
> >
> > Here I have to use HEAD@{5}.
> >
> 
> He meant using:
> 
> $ git reflog master

Indeed. That's why terse answers are often worse than no answers at all:
more often than not, they leave things unclearer than before, in the worst
case they are misleading, as was the very terse first reply. Just don't.
Too short is not beautiful.

> which only shows changes directly to the master ref, not to HEAD.
> During a git rebase operations don't modify the master ref until after
> the rebase finishes. This, of course, assumes you're on a branch.
> 
> If so, you should even be able to use master@{1} and be safe in
> assuming it always refers to what the branch was before the rebase
> started.

There are more tricks up Git's sleeves: @{1} is a shorthand for the
previous state of the current branch (if any). So after you rebase a
branch, @{1} will refer to what previously was ORIG_HEAD.

Having said that, it is an unintended regression in the built-in rebase.
Markus, could you come up with a minimal test case, preferably in the form
of a patch to t/t3415-rebase-autosquash.sh?

Thanks,
Johannes

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: git rebase: retain original head?
  2019-01-09 14:05       ` Johannes Schindelin
@ 2019-01-09 15:08         ` Markus Wiederkehr
  2019-01-11 10:42           ` Johannes Schindelin
  0 siblings, 1 reply; 9+ messages in thread
From: Markus Wiederkehr @ 2019-01-09 15:08 UTC (permalink / raw)
  To: Git mailing list

On Wed, Jan 9, 2019 at 3:05 PM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Having said that, it is an unintended regression in the built-in rebase.
> Markus, could you come up with a minimal test case, preferably in the form
> of a patch to t/t3415-rebase-autosquash.sh?

I don't think I'm familiar enough with the test code to be able to
provide a good patch but the following code should illustrate the
regression.

git init testrepo
cd testrepo
echo 1 > file && git add file && git commit -m "initial"
echo 1 >> file && git commit -am "commit 1"
# rev_commit_1=$(git rev-parse HEAD)
echo 1 >> file && git commit -am "fixup! $(git rev-parse --short HEAD)"
echo 1 >> file && git commit -am "commit 3"
rev_orig_head=$(git rev-parse HEAD)
GIT_EDITOR=: git rebase --autosquash -i HEAD~3
test $(git rev-parse ORIG_HEAD) = $rev_orig_head

In older versions of git this test succeeded, i.e. ORIG_HEAD pointed
to the previous original head, $rev_orig_head. In git version 2.20.1
ORIG_HEAD now points to the commit that got fixuped instead,
$rev_commit_1.

In previous versions ORIG_HEAD only pointed somewhere else if "git
reset" was invoked manually during the rebase operation. I'm not sure
if this is desirable, maybe ORIG_HEAD should always point to the
previous head after rebase completes, no matter what operations were
run in between. What do you think?

Markus

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: git rebase: retain original head?
  2019-01-09 15:08         ` Markus Wiederkehr
@ 2019-01-11 10:42           ` Johannes Schindelin
  0 siblings, 0 replies; 9+ messages in thread
From: Johannes Schindelin @ 2019-01-11 10:42 UTC (permalink / raw)
  To: Markus Wiederkehr; +Cc: Git mailing list

Hi Markus,

On Wed, 9 Jan 2019, Markus Wiederkehr wrote:

> On Wed, Jan 9, 2019 at 3:05 PM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > Having said that, it is an unintended regression in the built-in rebase.
> > Markus, could you come up with a minimal test case, preferably in the form
> > of a patch to t/t3415-rebase-autosquash.sh?
> 
> I don't think I'm familiar enough with the test code to be able to
> provide a good patch but the following code should illustrate the
> regression.

I think that you think you're too unfamiliar with the test code only
because you have not had a look.

> git init testrepo
> cd testrepo
> echo 1 > file && git add file && git commit -m "initial"

test_commit initial

> echo 1 >> file && git commit -am "commit 1"

test_commit 1 initial.t

> # rev_commit_1=$(git rev-parse HEAD)
> echo 1 >> file && git commit -am "fixup! $(git rev-parse --short HEAD)"

test_commit "fixup! 1" initial.t

> echo 1 >> file && git commit -am "commit 3"

test_commit 3 initial.t

> rev_orig_head=$(git rev-parse HEAD)
> GIT_EDITOR=: git rebase --autosquash -i HEAD~3
> test $(git rev-parse ORIG_HEAD) = $rev_orig_head

test_cmp_rev $rev_orig_head ORIG_HEAD

I leave it to you to make the actual patch.

Ciao,
Johannes

> 
> In older versions of git this test succeeded, i.e. ORIG_HEAD pointed
> to the previous original head, $rev_orig_head. In git version 2.20.1
> ORIG_HEAD now points to the commit that got fixuped instead,
> $rev_commit_1.
> 
> In previous versions ORIG_HEAD only pointed somewhere else if "git
> reset" was invoked manually during the rebase operation. I'm not sure
> if this is desirable, maybe ORIG_HEAD should always point to the
> previous head after rebase completes, no matter what operations were
> run in between. What do you think?
> 
> Markus
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-08 15:06 git rebase: retain original head? Markus Wiederkehr
2019-01-08 17:43 ` Andreas Schwab
2019-01-08 20:38   ` Markus Wiederkehr
2019-01-08 20:51     ` Andreas Schwab
2019-01-09 13:48       ` Markus Wiederkehr
2019-01-08 21:22     ` Jacob Keller
2019-01-09 14:05       ` Johannes Schindelin
2019-01-09 15:08         ` Markus Wiederkehr
2019-01-11 10:42           ` Johannes Schindelin

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox