Hello,
I'm running into a weird issue with git at the moment and I'm wondering
if this is a bug. I have a small reproduction path:
$ mkdir reproduction
$ cd reproduction
$ git init .
$ echo "commit a" > 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
$ git reset --hard HEAD^
$ git switch foo
Switched to branch 'foo'
Your branch is ahead of 'master' by 1 commit.
$ git log --format='%C(yellow)%h%Creset %Cgreen%s%Creset'
5f427e3 Third commit
03ad791 Second commit
411e6d4 First commit
$ git rebase master
$ git status
On branch foo
Your branch is up to date with 'master'.
$ git log --format='%C(yellow)%h%Creset %Cgreen%s%Creset'
03ad791 Second commit
411e6d4 First commit
I do not expect to lose the commits from foo, it seems the ref of master
doesn't get updated after a reset.
I didn't lose any work because I pushed my work to a remote and can
still get it from there (and git reflog would also reach my code). It is
rather surprising to see this kind of behavior.
I'm running:
$ git --version
git version 2.33.0.363.g4c719308ce
But I also got this behavior with the git shipped with Debian:
$ /usr/bin/git --version
git version 2.32.0
Cheers,
Wesley
--
Wesley Schwengle
E: wesley@schwengle.net
On Wed, Sep 15, 2021 at 11:29:14PM -0400, Wesley Schwengle wrote:
Hello,
I'm running into a weird issue with git at the moment and I'm wondering if
this is a bug. I have a small reproduction path:
$ git commit -m "First commit" file.txt
FWIW, I had to tweak this script a little, since file.txt is untracked
before it is added initially. (So a "git add file.txt" before this first
commit is required.)
But even after this, I got exactly what I expected from this script
(which was that your "foo" branch had three commits before and after).
Is there something else interesting going on with your setup that might
explain why I can't reproduce this?
Thanks,
Taylor
On 9/16/21 1:37 AM, Taylor Blau wrote:
FWIW, I had to tweak this script a little, since file.txt is untracked
before it is added initially. (So a "git add file.txt" before this first
commit is required.)
Oh sorry! I overlooked that part.
But even after this, I got exactly what I expected from this script
(which was that your "foo" branch had three commits before and after).
Is there something else interesting going on with your setup that might
explain why I can't reproduce this?
Oh, I found it.. Replace `git rebase master' with `git rebase' in the
reproduction path.
Disregard my post, it seems this is documented behavior in the rebase
man-page. When you have an upstream configured and you don't specify it
on the command line, --fork-point is used, while if you specify the
upstream --no-fork-point is used. `git rebase master --fork-point'
exhibits the same as I was seeing. Although I'm now completely confused
by this behavior. It doesn't make sense to me.
This happens:
We are on a branch, we merge it into another branch.
We undo the merge because reasons.
Now we git rebase, without the upstream, because we've set it.
Fork-point is used now, because we haven't specified an upstream, but we
did set it and git merge-base decides, oh, we had those commits in
master but these where dropped so we drop them in this branch as well.
New question, is there a way to tell rebase to NOT use fork-point via
git-config in this situation?
Cheers,
Wesley
--
Wesley Schwengle
E: wesley@schwengle.net
On 9/16/21 8:07 AM, Wesley Schwengle wrote:
New question, is there a way to tell rebase to NOT use fork-point via
git-config in this situation?
I seem to have found the answer in the source code: rebase.forkpoint exists.
Would you accept the following patch that adds the following text to the
documentation?
Cheers,
Wesley
From: Wesley Schwengle <redacted>
The option exists and the rebase behaviour tricked me into thinking
there was a bug with git. This will tell people how they can tweak the
default behavior.
Signed-off-by: Wesley Schwengle <redacted>
---
Documentation/git-rebase.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 506345cb0e..8d2bee3365 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -446,7 +446,8 @@ When --fork-point is active, 'fork_point' will be used instead of
ends up being empty, the <upstream> will be used as a fallback.
+
If <upstream> is given on the command line, then the default is
-`--no-fork-point`, otherwise the default is `--fork-point`.
+`--no-fork-point`, otherwise the default is `--fork-point`. You can override
+this default by setting the configuration option `rebase.forkpoint` to false.
+
If your branch was based on <upstream> but <upstream> was rewound and
your branch contains commits which were dropped, this option can be used
--
2.33.0.364.gff7047fb76