Elijah Newren <newren@xxxxxxxxx> writes: >> OK. These all ensure that when the history does not fast-forward, >> the command will fail when --ff-only tells us to allow only >> fast-forward. I am not sure "takes precedence" is a meaningful >> label, though. It is more like "ff-only means ff-only and fails >> when the upstream history is not a descendant, no matter how the >> possible integration is set to be performed". > > So, I think you're saying you view fast-forwards as a subset of valid > rebases (and fast-forwards are also a subset of valid rmerges), and > thus you view --ff-only --rebase as an instruction to only proceed if > both command line flags can be satisfied. Ah, I didn't think of it myself, but now you put it in these words, I do agree that the view makes sense. When we have nothing of our own, a degenerated form of a rebase is a fast-forward, even more so than a fast-forward being a degenerated form of a merge. > That makes sense, but I don't know how to put that into a test > description that isn't ridiculously long. Me neither. Let's not waste too much brain-cycles over this. Thanks.
