Re: Possible git bug

[Wesley Schwengle <wesley@schwengle.net>]

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