Re: [PATCH 1/2] builtin/rebase.c: Emit warning when rebasing without a forkpoint

From: Wesley <wesleys@opperschaap.net>
Date: Sep 1, 2023, 17:13 UTC
Message-ID: <a168fe69-f305-4280-b0e6-9406fbac796f@opperschaap.net>
In-Reply-To: <6127b570-5e9b-404f-9802-9135a1c9f31f@gmail.com>

Hello Phillip,

On 9/1/23 09:19, Phillip Wood wrote:

Show 39 quoted lines

> Hi Wesley
> 
> On 19/08/2023 21:34, Wesley Schwengle wrote:
>> When commit d1e894c6d7 (Document `rebase.forkpoint` in rebase man page,
>> 2021-09-16) was submitted there was a discussion on if the forkpoint
>> behaviour of `git rebase' was sane. In my experience this wasn't sane.
>> Git rebase doesn't work if you don't have an upstream branch configured
>> (or something that says `merge = refs/heads/master' in the git config).
>> The behaviour of `git rebase' was that if you supply an upstream on the
>> command line that it behaves as if `--no-forkpoint' was supplied and if
>> you don't supply an upstream, it behaves as if `--forkpoint' was
>> supplied. This can result in a loss of commits if you don't know that
>> and if you don't know about `git reflog' or have other copies of your
>> changes. This can be seen with the following reproduction path:
>>
>>      mkdir reproduction
>>      cd reproduction
>>      git init .
>>      echo "commit a" > file.txt
>>      git add file.txt
>>      git commit -m "First commit" file.txt
>>      echo "commit b" >> file.txt
>>      git commit -m "Second commit" file.txt
>>
>>      git switch -c foo
>>      echo "commit c" >> file.txt"
>>      git commit -m "Third commit" file.txt
>>      git branch --set-upstream-to=master
>>
>>      git status
>>      On branch foo
>>      Your branch is ahead of 'master' by 1 commit.
>>
>>      git switch master
>>      git merge foo
> 
> Here "git merge" fast-forwards I think, if instead it created a merge 
> commit there would be no problem as the tip of branch "foo" would not 
> end up in master's reflog.

If you do

git merge foo --no-ff git reset --hard HEAD^ git switch foo git rebase

You'll end up with just the commits that are in master. You'll lose all commits from foo.

>>      git log --format='%C(yellow)%h%Creset %Cgreen%s%Creset'
> 
> For a reproduction recipe I think "git log --oneline" would suffice.

Will update, thanks.

 >> [snip]

Show 5 quoted lines

> 
> Thanks for the detailed reproduction recipe, I think it would be helpful 
> to summarize what's happening in the commit message, especially as it 
> seems to depend on "git merge" fast-forwarding. Do you often merge a 
> branch into it's upstream and then reset the upstream branch?

Tricky question. When I encountered this behavior I was working on an epic/topic branch that I had locally. And I made a commit that I thought should have been in another branch. I moved the commit to another branch and than later on rebased it.

I didn't reply to Juno yet, but he refers to the discussion about --fork-point and --root command line options. This discussion links to a blogpost [*1*] where the same behavior is experienced.

The quirk is this: --fork-point looks at the reflog and reflog is local. Meaning, having an remote upstream branch will make --fork-point a noop. Only where you have an upstream which is local and your reflog has seen dropped commits it does something. In all other cases (including supplying the upstream) it behaves as if --no-fork-point was set. If you do the same action in two different clones, you get a different result, depending on what is in your reflog. I find this very tricky behavior for a default. I've set it to false myself, to get a more consistent behavior.

I usually have a remote upstream (gitlab/github) and work with that, so the --fork-point behaviour isn't present because there is no reflog for that, so it behaves as --no-fork-point.

Cheers, Wesley

[1]: https://commaok.xyz/post/fork-point/

-- 
Wesley

Why not both?