"Randall S. Becker" <rsbecker@xxxxxxxxxxxxx> writes: > On July 6, 2021 4:56 PM, Junio C Hamano wrote: >>"Randall S. Becker" <rsbecker@xxxxxxxxxxxxx> writes: >> >>>>If you do: >>>> >>>> % git merge --ff-only >>>> fatal: Not possible to fast-forward, aborting. >>>> >>>>That "aborting" part is redundant; we know `git merge` should abort >>> if the fast-forward is not possible, we explicitely told git to do >>> that. >>> >>> `git merge` is a special operation where errors (conflicts, for one) >>> may leave the repository in a merge pending state where you >>> subsequently may have to use `git merge --abort` to reset the >>> situation or `git add` to continue. The `aborting` output makes it >>> clear that you do not have to do the `--abort` and *cannot* do the >>> `add` because there was an implicit `--abort` done resulting from the >>> failure. This is important information for the user. >> >>If so, adding ", aborting" to the end is misleading. In this particular failure mode, the command pretends that the merge did not even >>start. > > You know that, and I know that. I contend that git users do not > generally want to care about failure modes. While a flow > description might be instructive, I doubt many git users would > look at it. We can only hope that front ends know how to make this > clean for them. They may not care about "failure modes" but they would want to know that in this situation, unlike other times, they do not have to say "git merge --abort" (or "git reset --hard"). Saying ", aborting" does not help as much as saying say ", not starting a merge", for example.
