Re: [PATCH 3/4] read-tree.c: rework UI when merging no trees
Le mercredi 3 mai 2017, 10:04:01 CEST Jonathan Nieder a écrit :
Show 14 quoted lines
> 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.
>
In fact, this patch is two fold:
* reword the question in the die() call. I realize now that when passed to
die(), the string is prepended with "fatal:". That's an hint that the question
does not require a reply, but ruling out any doubt would be better.
* rework the local logic which was inherited from history. This is
functionally equivalent to the previous version, just cleaner.
Show 26 quoted lines
> > 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.avila@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.
>
Thank you very much for this message! May I s-o-b you?
As hinted, I'll add the documentation part. ;-)
> Unfortunately both 'git read-tree -h' and 'git read-tree --help' say nothing
> about this. Ideas for wording there?
Next pach series will propose this.
>
> Thanks and hope that helps,
> Jonathan
Jean-Noël AVILA <jn.avila@free.fr>