Re: Possible git bug

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