Hi,
Jean-Noel Avila wrote:
> Subject: read-tree.c: rework UI when merging no trees
nit: this is about user-facing behavior, not an implementation detail,
so the part before the colon can be the command that changed
(read-tree:).
nit: the word "rework" is dangerous in a commit message in the same
way as the word "fix" --- it stands for "make better", in a vague way
that leaves the reader guessing about how. Usually a more specific
description can work better.
> The initial test was inherited from a previous commit, but it is no
> longer needed, given the following switch case. Moreover, the question
> sentence ending the program has been replace by an assertative one.
>
> Signed-off-by: Jean-Noel Avila <jn.av...@free.fr>
This can have a simpler, short-and-sweet motivation:
read-tree -m: make error message for merging 0 trees less smart-alecky
"git read-tree -m" requires a tree argument to name the tree to be
merged in. Git uses a cutesy error message to say so and why:
$ git read-tree -m
warning: read-tree: emptying the index with no arguments is
deprecated; use --empty
fatal: just how do you expect me to merge 0 trees?
$ git read-tree -m --empty
fatal: just how do you expect me to merge 0 trees?
When lucky, that could produce an ah-hah moment for the user, but it's
more likely to irritate and distract them.
Instead, tell the user plainly that the tree argument is required. Also
document this requirement in the git-read-tree(1) manpage where there is
room to explain it in a more straightforward way.
Unfortunately both 'git read-tree -h' and 'git read-tree --help' say nothing
about
this. Ideas for wording there?
Thanks and hope that helps,
Jonathan
