Re: Possible git bug
- From
- Wesley Schwengle <wesley@schwengle.net>
- Date
- Sep 16, 2021, 12:07 UTC
- Message-ID
- <c7949156-a7e5-085f-4779-82d0538a4d72@schwengle.net>
- In-Reply-To
- <YULYG970Ltnbshdn@nand.local>
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