2

I did some commits on branch MyCurrent. Then realize that I do them on another and leave current branch untouched.

Thus I create new branch at root point (where I should start new branch):

git checkout -b fixes 6735ff2

And check the root of branch:

$ git merge-base --fork-point fixes
6735ff23c52338fbaafbfa1707f0bcbb1e5b9698

Then I merge (maybe I should cherry-pick?) the current branch

$ git merge --ff-only MyCurrent
Updating 6735ff2..e1700a5
Fast-forward
...

When I check form-point again - it is moved:

git merge-base --fork-point fixes
e1700a59dd

Why fork point is updated?

Eugen Konkov
  • 22,193
  • 17
  • 108
  • 158
  • Incidentally, it occurs to me that you might think `git merge-base --fork-point` is intended to find the point at which the current branch forked from some parent branch. It's not—it does not do that at all, and *cannot* do it as branches don't record their parent. – torek Jun 30 '18 at 19:28

1 Answers1

2

git merge-base --fork-point uses the reflog:

For this answer, I looked at the source code. This shows that Git looks in the reflog of the first non-option argument—call this arg1—and then uses it to find a merge base using the next such argument arg2 resolved to a commit ID, completely ignoring any additional arguments. Based on this, the result of git merge-base --fork-point $arg1 $arg2 is essentially5 the output of:

git merge-base $arg2 $(git log -g --format=%H $arg1)

Since git merge --ff-only MyCurrent updated the reflog, adding a new commit hash, it's unsurprising that the --fork-point value would change. (Note that arg2 here defaults to HEAD, since you did not give one.)

(Note: the footnote explains where these results differ, along with an example. It's not literally exactly the same.)

See my (rather long) answer to git pull --rebase lost commits after coworker's git push --force (scroll down to the section labeled "The --fork-point option") for more.

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775
  • You have said that branch does not store info about the point it forked from. But how then `git log --graph --oneline` knows the point where branch is started? – Eugen Konkov Jul 05 '18 at 15:16
  • 1
    That's only true in simple cases. Suppose branch B is created at commit S (for start), then one makes N commits on B, then one merges B into M, then one makes more commits on B, and so on. Now, it is possible to read *this* graph and guess where the start was; but consider [Chris Johnsen's answer here](https://stackoverflow.com/a/3162929/1256452): Where did these branches start? – torek Jul 05 '18 at 18:55