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

[Wesley <wesleys@opperschaap.net>]

Hello Phillip,


On 9/1/23 09:19, Phillip Wood wrote:
> 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]
> 
> 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?