All these technicalities.
For someone to break the mainline parentage they would have to:
1. Do that ugly merge of mainline into their feature branch[1]
2. When they are ready to “incorporate” their commits into mainline: do a fast-forward since that’s apparently possible
But the proposed setup contradicts this chain of events: if their Git config was set up to do a fast-forward when possible, then a proper merge (a merge commit) wouldn’t have happened in stage 1 if mainline and `feature` had not diverged. And since that means that the two have diverged (evidenced by the merge commit), you cannot do a fast-forward in step 2.
And even if the above somehow is not true: step 2 is impossible because now `feature` contains a merge commit from mainline into `feature`, which mainline does not have. So a fast-forward is impossible.
What am I missing here?
[1] Oh right, I have to be specify now: a proper merge, a merge commit. The one with two parents, not an octopus one. Explicit enough already?
> You _want_ that to fast-forward when possible or everyone will create a merge commit every time they pull updates.
Surely this makes only a tiny difference in practice. We’re just a handful of developers and people usually diverge from mainline before they get their PR merged. So there are merge commits going from mainline into feature branches absolutely everywhere, because only two or three of us use rebase.
But I do in fact seem to recall talking to one of the other developers about him breaking the conventional commit parentage at some point in the history. So there is some bump there, a few years back.
But the usual story is that the people on our project do all those nasty merges on their own branches and then use the “merge” button in the Web UI when they get their PR approved. And there is in fact a fast-forward option there, but it’s not like we ever get to use it (unless we rebase) since mainline has diverged already. (I wouldn’t personally use it for “merging” (incorporating my changes) into mainline.)