More on fork-point

From: Martin Friebe <project@mfriebe.de>
To: Git List <git@vger.kernel.org>
Subject: More on fork-point
Date: Fri, 17 Sep 2021 13:58:11 +0200	[thread overview]
Message-ID: <8d74ce27-e3bf-792e-b767-c660a3cfc9e1@mfriebe.de> (raw)

Following the current conversation on fork-point, I found 2 
documentation bits that I wanted to bring up for discussion

1)
https://git-scm.com/docs/git-merge-base#_discussion_on_fork_point_mode
> (it includes B0, which is not what you wrote; it is a commit the other 
> side discarded when it moved its tip from B0 to B1).

This sentence makes 2 separate statements
A)  "not what you wrote": You only want to rebase commits you wrote 
yourself, but not commits the other side wrote
B)  "the other side discarded": That can apply to commits written 
originally by the other side, or originally written by you.

In the context of the doc, it is easy to read "B" as "discarded commits, 
that the other side had written".
Leaving it unclear, what would happen if the other side, discard commits 
(from their branch) that you wrote in your branch.

Also the example graph in the doc, shows that the commits discarded by 
the other side, where commits written by the other side.

In the "Potential git bug" thread, this is what happens.
- A commit is made to branch foo
- the other side (branch master) includes that commit (which you wrote)
   git switch master
   git merge foo
- the other side drops/discards this commit
   git reset --hard HEAD^

So now "master" has dropped a commit you wrote.
When you "rebase --fork-point" do you want
a) commits you wrote (and only you wrote)
b) exclude commits discarded by the other side, even though they where 
yours originally?

Should removing/undoing  a merge mean:
- The merge should be prevented in future
- The merge is undone now, and may be done again in future.

Depending on this the behaviour of --fork-point may have to be adjusted.

Also, if the other side "master" was a remote branch. And my work was 
merged and then removed (on the remote), then what will happen?
Will by git repo be aware that the commit was "rejected"? Will it depend 
if I pulled while it was part of the other branch, so that I then had to 
"git reset" my local master to follow the forced push?

------------
Btw, something else I have not tested, but what should happen if:

X -> A -> A1 -> A2 -> A3
        \ -> B1 -> B2 -> A2 -> B3

"A2" was cherry picked into the "B" branch.
The "A" branch is rewritten to be
A1 -> A3

X ->  A1 -> A3
      \ -> A ->  B1 -> B2 -> A2 -> B3

fork-point would mean that B1..B3 will be replayed.
But should A2 be included in a fork-point rebase of B onta A?

This does matter, when reading the "rebase" docs. See the quote below, 
which contains "which commits have been introduced by <branch>."
"A2" was not introduced by my branch.

=====================
2)
https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---no-fork-point
> Use reflog to find a better common ancestor between <upstream> and 
> <branch> when calculating which commits have been introduced by <branch>.
And then, only at the end of the paragraph
> If your branch was based on <upstream> but <upstream> was rewound and 
> your branch contains commits which were dropped, this option can be 
> used with |--keep-base| in order to drop those commits from your branch.

Imho the part that "dropped commits from the other side, will not be 
re-introduced" is the key statement. Maybe that should move up?
But more important, why should this statement be limited to the context 
of keep-base"?
Maybe it should be

     If your branch was based on <upstream> but <upstream> was rewound 
and your branch contains commits which were dropped, this option will 
exclude those commits from being replayed. This
  can be used with |--keep-base| .

I am aware that is basically a summary of the "merge point" 
documentation (and hence a repeat). But the repeat is already in the 
"rebase" documentation.