Git Rebase Issue

Git Rebase Issue

[Pierre-Luc Loyer]

Hi,

I've encountered a situation using rebase for which I don't understand the results, even after reading the documentation.
I'm currently working in my feature branch and then I want to squash commits, thus I use interactive rebase. After successfully completing the rebase, I end up in a detached HEAD state, rather than back on my branch, which is confusing. The command that is causing me to be in detached HEAD mode is: git rebase -i HEAD~2 HEAD
From the documentation, I read that my second parameter (HEAD) is the <branch> parameter:

   git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]

   [<upstream>] [<branch>]

   If <branch> is specified, git rebase will perform an automatic git checkout <branch> before doing anything else. Otherwise it remains on the current branch.
<branch> Working branch; defaults to HEAD.

   Upon completion, <branch> will be the current branch.

Here is a full example than can be used to easily repro the issue. Go to an empty folder.
git init
git echo text > file.txt
git add .
git commit -m "Add file.txt"
git echo text2 > file.txt
git commit -am "Modify file.txt"
git echo text3 > file.txt
git commit -am "Remodify file.txt"

Now the interesting part:
$ git rebase -i HEAD~2 HEAD
[detached HEAD 9178b93] Modify file
1 file changed, 1 insertion(+), 1 deletion(-)
Successfully rebased and updated detached HEAD. 

From the documentation it says that <branch> (which is HEAD) will be checked out before doing anything and that upon completion, <branch> will be the current branch. However, this doesn't seem to happen. In fact, it seems more like the following is happening during the rebase:
1) detach HEAD
2) rebase
3) reattach to <branch>

If <branch> is HEAD, then is does nothing and remains detached.
I find this behavior confusing since I would expect it to return to whatever HEAD was pointing to at the start of the command, such as my branch. Also, the documentation says that the <branch> parameter defaults to HEAD, so passing 'HEAD' explicitly should result in the same behavior as not passing it:
<branch> Working branch; defaults to HEAD.

Pierre-Luc Loyer

Re: Git Rebase Issue

[Junio C Hamano]

Pierre-Luc Loyer <Pierre-Luc.Loyer@bhvr.com> writes:

> From the documentation it says that <branch> (which is HEAD) will be checked out before doing anything and that upon completion, <branch> will be the current branch. However, this doesn't seem to happen. In fact, it seems more like the following is happening during the rebase:
> 1) detach HEAD
> 2) rebase
> 3) reattach to <branch>

You do not have to say "HEAD" for "<branch>", if you are rebasing
the current branch.  Either leave it unsaid, or name the branch.

Passing "HEAD" (or any of its variants that names the exact commit
at the tip of the current branch, without using the name of the
current branch, e.g. "master^0") as the "branch to rebase" is an
advanced technique to use when you want to avoid messing with the
branch itself.  It is deliberate that the HEAD is left detached.

You'd (once you learn Git sufficently and got comfortable with
working on a detached HEAD, that is) often find yourself doing
things like this:

1. rebase temporarily on detached HEAD

    $ git rebase -i HEAD~2 HEAD ;# amend the tip two

2. double check the result and convince yourself that it is better
   than the original

    $ git diff master HEAD

    $ git log master.. >updated
    $ git log -2 master >original
    $ diff -u original updated

3-a. once satisfied, update the branch

    $ git checkout -B master

3-b. or abandon if the result is undesirable.

    $ git checkout master

Re: Git Rebase Issue

[Christian Couder]

Hi,

On Tue, Dec 22, 2015 at 6:53 PM, Pierre-Luc Loyer
<Pierre-Luc.Loyer@bhvr.com> wrote:
> Hi,
>
> I've encountered a situation using rebase for which I don't understand the results, even after reading the documentation.
> I'm currently working in my feature branch and then I want to squash commits, thus I use interactive rebase. After successfully completing the rebase, I end up in a detached HEAD state, rather than back on my branch, which is confusing. The command that is causing me to be in detached HEAD mode is: git rebase -i HEAD~2 HEAD
> From the documentation, I read that my second parameter (HEAD) is the <branch> parameter:
>
>    git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
>
>    [<upstream>] [<branch>]
>
>    If <branch> is specified, git rebase will perform an automatic git checkout <branch> before doing anything else. Otherwise it remains on the current branch.
> <branch> Working branch; defaults to HEAD.
>
>    Upon completion, <branch> will be the current branch.
>
> Here is a full example than can be used to easily repro the issue. Go to an empty folder.
> git init
> git echo text > file.txt
> git add .
> git commit -m "Add file.txt"
> git echo text2 > file.txt
> git commit -am "Modify file.txt"
> git echo text3 > file.txt
> git commit -am "Remodify file.txt"
>
> Now the interesting part:
> $ git rebase -i HEAD~2 HEAD
> [detached HEAD 9178b93] Modify file
> 1 file changed, 1 insertion(+), 1 deletion(-)
> Successfully rebased and updated detached HEAD.
>
> From the documentation it says that <branch> (which is HEAD) will be checked out before doing anything and that upon completion, <branch> will be the current branch. However, this doesn't seem to happen. In fact, it seems more like the following is happening during the rebase:
> 1) detach HEAD
> 2) rebase
> 3) reattach to <branch>
>
> If <branch> is HEAD, then is does nothing and remains detached.
> I find this behavior confusing since I would expect it to return to whatever HEAD was pointing to at the start of the command, such as my branch. Also, the documentation says that the <branch> parameter defaults to HEAD, so passing 'HEAD' explicitly should result in the same behavior as not passing it:
> <branch> Working branch; defaults to HEAD.

You are right, it is probably a bug.
I guess usually people just use "git rebase -i HEAD~2" or "git rebase
-i master" and don't give the [<branch>] argument when using -i.

If you are interested in helping us debug this you might first want to
check if older git versions behaved like this.

Thanks,
Christian.

git rebase issue

[Andy Shevchenko]

Hi!

Recently Debian has updated the Git to 2.39.2 and broke my user case
(I believe it's a problem in the Git itself and not Debian packaging
or so).

So, my use case is to run

  git rebase --rebase-merges -X ours --onto "$newbase" "$oldbase" "$branch"

in the repository that is made out of bare + a few worktrees.

Previously everything was working (my bare repository points to one of
the existing branch:
In shell prompt: ...(BARE:netboot)]$

With the new release I have got an error

  fatal: 'netboot' is already checked out at ...

To work around this I have to split the above to

  git checkout --ignore-other-worktrees "$branch"
  git rebase --rebase-merges -X ours --onto "$newbase" "$oldbase"

which makes all these too inconvenient.

Any suggestions?

-- 
With Best Regards,
Andy Shevchenko

Re: git rebase issue

[Andy Shevchenko]

On Mon, Mar 13, 2023 at 2:35 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> Hi!
>
> Recently Debian has updated the Git to 2.39.2 and broke my user case
> (I believe it's a problem in the Git itself and not Debian packaging
> or so).

Forgot to add that last week it was working nicely (I don't remember
the version, but according to Debian changelog it looks like 2.38.4
was working fine to me.

> So, my use case is to run
>
>   git rebase --rebase-merges -X ours --onto "$newbase" "$oldbase" "$branch"
>
> in the repository that is made out of bare + a few worktrees.
>
> Previously everything was working (my bare repository points to one of
> the existing branch:
> In shell prompt: ...(BARE:netboot)]$
>
> With the new release I have got an error
>
>   fatal: 'netboot' is already checked out at ...
>
> To work around this I have to split the above to
>
>   git checkout --ignore-other-worktrees "$branch"
>   git rebase --rebase-merges -X ours --onto "$newbase" "$oldbase"
>
> which makes all these too inconvenient.
>
> Any suggestions?

-- 
With Best Regards,
Andy Shevchenko

Re: git rebase issue

[Andy Shevchenko]

On Mon, Mar 13, 2023 at 2:58 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, Mar 13, 2023 at 2:35 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> >
> > Hi!
> >
> > Recently Debian has updated the Git to 2.39.2 and broke my user case
> > (I believe it's a problem in the Git itself and not Debian packaging
> > or so).
>
> Forgot to add that last week it was working nicely (I don't remember
> the version, but according to Debian changelog it looks like 2.38.4
> was working fine to me.
>
> > So, my use case is to run
> >
> >   git rebase --rebase-merges -X ours --onto "$newbase" "$oldbase" "$branch"
> >
> > in the repository that is made out of bare + a few worktrees.
> >
> > Previously everything was working (my bare repository points to one of
> > the existing branch:
> > In shell prompt: ...(BARE:netboot)]$
> >
> > With the new release I have got an error
> >
> >   fatal: 'netboot' is already checked out at ...
> >
> > To work around this I have to split the above to
> >
> >   git checkout --ignore-other-worktrees "$branch"
> >   git rebase --rebase-merges -X ours --onto "$newbase" "$oldbase"
> >
> > which makes all these too inconvenient.
> >
> > Any suggestions?

So, what should I do? Today I got again to help manually with my (used
to working) scripts.


-- 
With Best Regards,
Andy Shevchenko

Re: git rebase issue

[Felipe Contreras]

On Mon, Mar 20, 2023 at 6:32 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Mon, Mar 13, 2023 at 2:58 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Mon, Mar 13, 2023 at 2:35 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > >
> > > Hi!
> > >
> > > Recently Debian has updated the Git to 2.39.2 and broke my user case
> > > (I believe it's a problem in the Git itself and not Debian packaging
> > > or so).
> >
> > Forgot to add that last week it was working nicely (I don't remember
> > the version, but according to Debian changelog it looks like 2.38.4
> > was working fine to me.
> >
> > > So, my use case is to run
> > >
> > >   git rebase --rebase-merges -X ours --onto "$newbase" "$oldbase" "$branch"
> > >
> > > in the repository that is made out of bare + a few worktrees.
> > >
> > > Previously everything was working (my bare repository points to one of
> > > the existing branch:
> > > In shell prompt: ...(BARE:netboot)]$
> > >
> > > With the new release I have got an error
> > >
> > >   fatal: 'netboot' is already checked out at ...
> > >
> > > To work around this I have to split the above to
> > >
> > >   git checkout --ignore-other-worktrees "$branch"
> > >   git rebase --rebase-merges -X ours --onto "$newbase" "$oldbase"
> > >
> > > which makes all these too inconvenient.
> > >
> > > Any suggestions?
>
> So, what should I do? Today I got again to help manually with my (used
> to working) scripts.

Do you have a sequence of steps to reproduce the issue?

With that it should be trivial to do `git bisect` and figure out which
commit introduced the regression.

-- 
Felipe Contreras

Re: git rebase issue

[Jeff King]

[Please don't put random folks in the to/cc unless you think they have
specific knowledge related to your problem.]

On Mon, Mar 20, 2023 at 02:10:38PM +0200, Andy Shevchenko wrote:

> > > With the new release I have got an error
> > >
> > >   fatal: 'netboot' is already checked out at ...
> > >
> > > To work around this I have to split the above to
> > >
> > >   git checkout --ignore-other-worktrees "$branch"
> > >   git rebase --rebase-merges -X ours --onto "$newbase" "$oldbase"
> > >
> > > which makes all these too inconvenient.
> > >
> > > Any suggestions?
> 
> So, what should I do? Today I got again to help manually with my (used
> to working) scripts.

Running "git log --grep=already.checked.out" suggests that it may be
b5cabb4a967 (rebase: refuse to switch to branch already checked out
elsewhere, 2020-02-23).

Adding its author to the cc, who may be able to say more. But my
understanding is that this was probably fixing a bug (though I don't
know all the implications of having a branch checked out in multiple
worktrees).

-Peff

Re: git rebase issue

[Andy Shevchenko]

On Mon, Mar 20, 2023 at 7:02 PM Jeff King <peff@peff.net> wrote:


> [Please don't put random folks in the to/cc unless you think they have
> specific knowledge related to your problem.]

Sorry about that, but my reaction was to the silence. I found your
name is a top contributor, so that's why I have chosen your name.

> On Mon, Mar 20, 2023 at 02:10:38PM +0200, Andy Shevchenko wrote:
>
> > > > With the new release I have got an error
> > > >
> > > >   fatal: 'netboot' is already checked out at ...
> > > >
> > > > To work around this I have to split the above to
> > > >
> > > >   git checkout --ignore-other-worktrees "$branch"
> > > >   git rebase --rebase-merges -X ours --onto "$newbase" "$oldbase"
> > > >
> > > > which makes all these too inconvenient.
> > > >
> > > > Any suggestions?
> >
> > So, what should I do? Today I got again to help manually with my (used
> > to working) scripts.
>
> Running "git log --grep=already.checked.out" suggests that it may be
> b5cabb4a967 (rebase: refuse to switch to branch already checked out
> elsewhere, 2020-02-23).

Thank you.

Indeed, reverting that (manually as it's a conflict with v2.40.0
current tree) fixes my issue.

> Adding its author to the cc, who may be able to say more. But my
> understanding is that this was probably fixing a bug (though I don't
> know all the implications of having a branch checked out in multiple
> worktrees).

Note, in my case it's "checked" in the BARE repository, which means
it's actually not.
This case shouldn't be an impediment or racy AFAIU.

-- 
With Best Regards,
Andy Shevchenko

Re: git rebase issue

[Felipe Contreras]

On Mon, Mar 20, 2023 at 12:11 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, Mar 20, 2023 at 7:02 PM Jeff King <peff@peff.net> wrote:

> > Adding its author to the cc, who may be able to say more. But my
> > understanding is that this was probably fixing a bug (though I don't
> > know all the implications of having a branch checked out in multiple
> > worktrees).
>
> Note, in my case it's "checked" in the BARE repository, which means
> it's actually not.
> This case shouldn't be an impediment or racy AFAIU.

In that case I agree it should work, but when I tried to reproduce the
issue the bare repository is ignored, only worktrees are considered.

Are you sure the branch isn't checked out in other worktree(s)?

-- 
Felipe Contreras

Re: git rebase issue

[Andy Shevchenko]

On Thu, Mar 23, 2023 at 10:38 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Mon, Mar 20, 2023 at 12:11 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Mon, Mar 20, 2023 at 7:02 PM Jeff King <peff@peff.net> wrote:
>
> > > Adding its author to the cc, who may be able to say more. But my
> > > understanding is that this was probably fixing a bug (though I don't
> > > know all the implications of having a branch checked out in multiple
> > > worktrees).
> >
> > Note, in my case it's "checked" in the BARE repository, which means
> > it's actually not.
> > This case shouldn't be an impediment or racy AFAIU.
>
> In that case I agree it should work, but when I tried to reproduce the
> issue the bare repository is ignored, only worktrees are considered.
>
> Are you sure the branch isn't checked out in other worktree(s)?

Yes. Since the commit was in v2.26 already, and I have noticed the
issue only recently, there are a few possibilities:
1) Debian is to slow to update a Git (doesn't sound like the case);
2) New version of the Git does something in the configuration files
that unveils the issue;
3) Something else I've been missing?

As for 2) I have found a new config.worktree which I tried to remove,
nothing changed. Also I disabled extended worktree configuration in
the main (~/.gitconfig) one. Didn't help either.

I have a bare repo with a Linux kernel and two worktrees. The HEAD in
the bare points out to one of the branches which I try to rebase.

BARE:xxx (as shown by Git prompt helper in the Bash)

`git rebase -X ours --onto "vN+1" "vN" xxx` fails.


-- 
With Best Regards,
Andy Shevchenko