{"thread":{"id":"56524","subject":"More on fork-point","startedAt":"2021-09-17T16:41:04Z","lastAt":"2021-09-17T16:41:04Z","messageCount":1,"participants":["Martin Friebe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"436233","messageId":"8d74ce27-e3bf-792e-b767-c660a3cfc9e1@mfriebe.de","threadId":"56524","inReplyTo":null,"subject":"More on fork-point","fromName":"Martin Friebe","fromEmail":"project@mfriebe.de","sentAt":"2021-09-17T11:58:11Z","receivedAt":"2021-09-17T16:41:04Z","isPatch":false,"sender":{"key":"project@mfriebe.de","avatar":null},"body":"Following the current conversation on fork-point, I found 2 \ndocumentation bits that I wanted to bring up for discussion\n\n1)\nhttps://git-scm.com/docs/git-merge-base#_discussion_on_fork_point_mode\n> (it includes B0, which is not what you wrote; it is a commit the other \n> side discarded when it moved its tip from B0 to B1).\n\nThis sentence makes 2 separate statements\nA)  \"not what you wrote\": You only want to rebase commits you wrote \nyourself, but not commits the other side wrote\nB)  \"the other side discarded\": That can apply to commits written \noriginally by the other side, or originally written by you.\n\nIn the context of the doc, it is easy to read \"B\" as \"discarded commits, \nthat the other side had written\".\nLeaving it unclear, what would happen if the other side, discard commits \n(from their branch) that you wrote in your branch.\n\nAlso the example graph in the doc, shows that the commits discarded by \nthe other side, where commits written by the other side.\n\nIn the \"Potential git bug\" thread, this is what happens.\n- A commit is made to branch foo\n- the other side (branch master) includes that commit (which you wrote)\n   git switch master\n   git merge foo\n- the other side drops/discards this commit\n   git reset --hard HEAD^\n\nSo now \"master\" has dropped a commit you wrote.\nWhen you \"rebase --fork-point\" do you want\na) commits you wrote (and only you wrote)\nb) exclude commits discarded by the other side, even though they where \nyours originally?\n\nShould removing/undoing  a merge mean:\n- The merge should be prevented in future\n- The merge is undone now, and may be done again in future.\n\nDepending on this the behaviour of --fork-point may have to be adjusted.\n\nAlso, if the other side \"master\" was a remote branch. And my work was \nmerged and then removed (on the remote), then what will happen?\nWill by git repo be aware that the commit was \"rejected\"? Will it depend \nif I pulled while it was part of the other branch, so that I then had to \n\"git reset\" my local master to follow the forced push?\n\n------------\nBtw, something else I have not tested, but what should happen if:\n\nX -> A -> A1 -> A2 -> A3\n        \\ -> B1 -> B2 -> A2 -> B3\n\n\"A2\" was cherry picked into the \"B\" branch.\nThe \"A\" branch is rewritten to be\nA1 -> A3\n\nX ->  A1 -> A3\n      \\ -> A ->  B1 -> B2 -> A2 -> B3\n\nfork-point would mean that B1..B3 will be replayed.\nBut should A2 be included in a fork-point rebase of B onta A?\n\nThis does matter, when reading the \"rebase\" docs. See the quote below, \nwhich contains \"which commits have been introduced by <branch>.\"\n\"A2\" was not introduced by my branch.\n\n=====================\n2)\nhttps://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---no-fork-point\n> Use reflog to find a better common ancestor between <upstream> and \n> <branch> when calculating which commits have been introduced by <branch>.\nAnd then, only at the end of the paragraph\n> If your branch was based on <upstream> but <upstream> was rewound and \n> your branch contains commits which were dropped, this option can be \n> used with |--keep-base| in order to drop those commits from your branch.\n\nImho the part that \"dropped commits from the other side, will not be \nre-introduced\" is the key statement. Maybe that should move up?\nBut more important, why should this statement be limited to the context \nof keep-base\"?\nMaybe it should be\n\n     If your branch was based on <upstream> but <upstream> was rewound \nand your branch contains commits which were dropped, this option will \nexclude those commits from being replayed. This\n  can be used with |--keep-base| .\n\nI am aware that is basically a summary of the \"merge point\" \ndocumentation (and hence a repeat). But the repeat is already in the \n\"rebase\" documentation.\n\n\n"}]}