Re: [PATCH 3/4] read-tree.c: rework UI when merging no trees

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 3, 2017, 17:04 UTC
Message-ID: <20170503170401.GA28740@aiede.svl.corp.google.com>
In-Reply-To: <20170503162931.30721-3-jn.avila@free.fr>

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.

Show 5 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.

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