On July 6, 2021 5:54 PM Junio C Hamano wrote: >"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. I like that a lot, actually "not starting a merge" is much more helpful.
