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?
