threads / discuss / 59617

Git rebase no longer defaults to upstream after force push

Subject: Git rebase no longer defaults to upstream after force push

## tl;dr

6 messages between Apr 18, 2023 and Apr 19, 2023.

replies: 5people: 5as markdown or json

Erik Cervin Edin· Apr 18, 2023, 09:17 UTC · lore

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
  git init --bare foo.git && git clone foo.git/ foo && cd foo
  touch bar && git add bar && git commit -m init
  git push -u
  git switch -c a
  seq 1 3 > bar && git add bar && git commit -m 1
  git push
  seq 11 13 > bar && git add bar && git commit -m 2
  git rebase -ir # Works like git rebase -ir @{upstream}
  git push --force origin main:a
  git rebase -ir # No longer works like git rebase -ir @{upstream}
What did you expect to happen? (Expected behavior)

After force pushing, I still expected the rebase to work like git rebase -ir @{upstream}.

What happened instead? (Actual behavior)

The rebase defaults to a commit other than that of the tip of the upstream branch.

What's different between what you expected and what actually happened?

Instead of behaving like git rebase @{upstream}, the rebase seems to default to rebasing on-top of the old upstream.

git rebase -ir result in a todo like this:
l onto

t onto p f1cfbff 2023-04-18 2

Compared to git rebase -ir @{upstream} which results in a todo like this:
l onto

t onto p 01e3c92 2023-04-18 1 p f1cfbff 2023-04-18 2

Anything else you want to add:

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.40.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 compiler info: gnuc: 11.3 libc info: glibc: 2.35 $SHELL (typically, interactive shell): /bin/bash

[Enabled Hooks]
-- 
Erik Cervin-Edin
Phillip Wood· Apr 18, 2023, 14:01 UTC · re: Erik Cervin Edin · lore

Re: Git rebase no longer defaults to upstream after force push

Hi Erik

Thanks for reporting this, unfortunately without knowing more about your config settings it is hard to tell what is happening here.

On 18/04/2023 10:17, Erik Cervin Edin wrote:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
 >
Show 5 quoted lines
> What did you do before the bug happened? (Steps to reproduce your issue)
> 
>    git init --bare foo.git && git clone foo.git/ foo && cd foo
>    touch bar && git add bar && git commit -m init
>    git push -u

This sets the upstream branch for main to origin/main, (assuming push.default allows pushing without specifying a refspec)

>    git switch -c a

Here you create a new branch, whether switch sets an upstream for it depends on the value of branch.autoSetupMerge. The default is not to set an upstream branch in this case. If you have set branch.autoSetupMerge to "always" then the upstream branch will be "main", if branch.autoSetupMerge is set to "inherit" then the upstream branch will be "origin/main". What does branch -vv show?

>    seq 1 3 > bar && git add bar && git commit -m 1
>    git push

What happens here depends on push.default, branch.autoSetupMerge and push.autoSetupRemote. If switch did not set an upstream branch then push will if you have push.autoSetupRemote enabled.

>    seq 11 13 > bar && git add bar && git commit -m 2
>    git rebase -ir # Works like git rebase -ir @{upstream}
>    git push --force origin main:a
>    git rebase -ir # No longer works like git rebase -ir @{upstream}

Without knowing what the upstream branch is it is hard to say what is going on here.

Best Wishes
Phillip
Show 53 quoted lines
> What did you expect to happen? (Expected behavior)
> 
> After force pushing, I still expected the rebase to work like git
> rebase -ir @{upstream}.
> 
> What happened instead? (Actual behavior)
> 
> The rebase defaults to a commit other than that of the tip of the
> upstream branch.
> 
> What's different between what you expected and what actually happened?
> 
> Instead of behaving like git rebase @{upstream}, the rebase seems to
> default to rebasing on-top of the old upstream.
> 
> git rebase -ir result in a todo like this:
> 
> l onto
> 
> t onto
> p f1cfbff 2023-04-18    2
> 
> Compared to git rebase -ir @{upstream} which results in a todo like this:
> 
> l onto
> 
> t onto
> p 01e3c92 2023-04-18    1
> p f1cfbff 2023-04-18    2
> 
> Anything else you want to add:
> 
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
> 
> 
> [System Info]
> git version:
> git version 2.40.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Linux 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27
> 02:56:13 UTC 2023 x86_64
> compiler info: gnuc: 11.3
> libc info: glibc: 2.35
> $SHELL (typically, interactive shell): /bin/bash
> 
> 
> [Enabled Hooks]
>
Cem Gündoğdu· Apr 18, 2023, 15:54 UTC · re: Erik Cervin Edin · lore

Re: Git rebase no longer defaults to upstream after force push

Hi Erik,
From documentation:
> If <upstream> is not specified, [...] and the --fork-point option is assumed.
The --fork-point option does this:
> Use reflog to find a better common ancestor between <upstream> and <branch> when calculating which commits have been introduced by <branch>.

Since the parent of a is still in the reflog of origin/a, it is not being rebased (the rationale being that the commit *was* in origin/a at some point). If you want to disable this behavior, add --no-fork-point option:

git rebase -ir --no-fork-point
Since this is the documented behavior, it probably is not a bug.

Best, Cem

On Tue, Apr 18, 2023 at 11:34 AM Erik Cervin Edin <erik@cervined.in> wrote:
Show 72 quoted lines
>
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
>
>   git init --bare foo.git && git clone foo.git/ foo && cd foo
>   touch bar && git add bar && git commit -m init
>   git push -u
>   git switch -c a
>   seq 1 3 > bar && git add bar && git commit -m 1
>   git push
>   seq 11 13 > bar && git add bar && git commit -m 2
>   git rebase -ir # Works like git rebase -ir @{upstream}
>   git push --force origin main:a
>   git rebase -ir # No longer works like git rebase -ir @{upstream}
>
> What did you expect to happen? (Expected behavior)
>
> After force pushing, I still expected the rebase to work like git
> rebase -ir @{upstream}.
>
> What happened instead? (Actual behavior)
>
> The rebase defaults to a commit other than that of the tip of the
> upstream branch.
>
> What's different between what you expected and what actually happened?
>
> Instead of behaving like git rebase @{upstream}, the rebase seems to
> default to rebasing on-top of the old upstream.
>
> git rebase -ir result in a todo like this:
>
> l onto
>
> t onto
> p f1cfbff 2023-04-18    2
>
> Compared to git rebase -ir @{upstream} which results in a todo like this:
>
> l onto
>
> t onto
> p 01e3c92 2023-04-18    1
> p f1cfbff 2023-04-18    2
>
> Anything else you want to add:
>
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
>
>
> [System Info]
> git version:
> git version 2.40.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Linux 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27
> 02:56:13 UTC 2023 x86_64
> compiler info: gnuc: 11.3
> libc info: glibc: 2.35
> $SHELL (typically, interactive shell): /bin/bash
>
>
> [Enabled Hooks]
>
> --
> Erik Cervin-Edin
Erik Cervin Edin· Apr 19, 2023, 15:43 UTC · re: Cem Gündoğdu · lore

Re: Git rebase no longer defaults to upstream after force push

On Tue, Apr 18, 2023 at 5:54 PM Cem Gündoğdu <cscallsign@gmail.com> wrote:
Show 10 quoted lines
> > If <upstream> is not specified, [...] and the --fork-point option is assumed.
>
> The --fork-point option does this:
>
> > Use reflog to find a better common ancestor between <upstream> and <branch> when calculating which commits have been introduced by <branch>.
>
> Since the parent of a is still in the reflog of origin/a, it is not
> being rebased (the rationale being that the commit *was* in origin/a
> at some point). If you want to disable this behavior, add
> --no-fork-point option:

Yes. That's it, thank you for pointing out --fork-point. That's indeed what's causing the unexpected behavior.

Do you happen to know when such behavior is desirable? I'm tempted to change the default to --no-fork-point but usually when something is default there's a valid reason.. 🤔

Sergey Organov· Apr 19, 2023, 17:03 UTC · re: Erik Cervin Edin · lore

Re: Git rebase no longer defaults to upstream after force push

Erik Cervin Edin <erik@cervined.in> writes:
Show 20 quoted lines
> On Tue, Apr 18, 2023 at 5:54 PM Cem Gündoğdu <cscallsign@gmail.com> wrote:
>> > If <upstream> is not specified, [...] and the --fork-point option is assumed.
>>
>> The --fork-point option does this:
>>
>> > Use reflog to find a better common ancestor between <upstream> and
>> > <branch> when calculating which commits have been introduced by
>> > <branch>.
>>
>> Since the parent of a is still in the reflog of origin/a, it is not
>> being rebased (the rationale being that the commit *was* in origin/a
>> at some point). If you want to disable this behavior, add
>> --no-fork-point option:
>
> Yes. That's it, thank you for pointing out --fork-point. That's indeed
> what's causing the unexpected behavior.
>
> Do you happen to know when such behavior is desirable? I'm tempted to
> change the default to --no-fork-point but usually when something is
> default there's a valid reason.. 🤔
$ git help merge-base
has a thorough discussion of --fork-point that might be helpful.

As far as I understand, it helps to DWYM when remote branch has been rewound, and causes nasty confusion when it fires unintentionally. 

-- Sergey
Felipe Contreras· Apr 19, 2023, 00:06 UTC · re: Erik Cervin Edin · lore

Re: Git rebase no longer defaults to upstream after force push

Erik Cervin Edin wrote:
Show 11 quoted lines
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
> 
> What did you do before the bug happened? (Steps to reproduce your issue)
> 
>   git init --bare foo.git && git clone foo.git/ foo && cd foo
>   touch bar && git add bar && git commit -m init
>   git push -u
>   git switch -c a
>   seq 1 3 > bar && git add bar && git commit -m 1
>   git push
For me it fails at this point.
  fatal: The upstream branch of your current branch does not match
  the name of your current branch.  To push to the upstream branch
  on the remote, use
      git push . HEAD:master
  To push to the branch of the same name on the remote, use
      git push . HEAD
  To choose either option permanently, see push.default in 'git help config'.
  To avoid automatically configuring an upstream branch when its name
  won't match the local branch, see option 'simple' of branch.autoSetupMerge
  in 'git help config'.
What's your configured push.default?
>   seq 11 13 > bar && git add bar && git commit -m 2
>   git rebase -ir # Works like git rebase -ir @{upstream}
>   git push --force origin main:a
>   git rebase -ir # No longer works like git rebase -ir @{upstream}
This works fine here.
-- 
Felipe Contreras

← back to recent threads