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@xxxxxxxxxxxxx
