Subject: Re: [PATCH 2/4] usability: fix am and checkout for nevermind questions

From: Jean-Noël AVILA <[email-masked]>
Date: Wed, 03 May 2017 20:35:06 +0200

Le mercredi 3 mai 2017 09:51:58 CEST, vous avez écrit :
> Jean-Noel Avila wrote:
> > Subject: usability: fix am and checkout for nevermind questions
> > 
> > Signed-off-by: Jean-Noel Avila <[email-masked]>
> 
> Thanks for working on improving Git's UX.  I agree with the goal in
> general (we should not gratuitously surprise users) but I think I
> lack context for appreciating this particular example.
> 
> This is a good place to describe the motivation behind the patch and
> what effective change it would have.
> 
> [...]
> 
> > +++ b/builtin/am.c
> 
> [...]
> 
> >  	if (is_empty_file(am_path(state, "patch"))) {
> > 
> > -		printf_ln(_("Patch is empty. Was it split wrong?"));
> > +		printf_ln(_("Patch is empty. It may have been split wrong."));
> 
> [...]
> 
> >  	if (unmerged_cache()) {
> >  	
> >  		printf_ln(_("You still have unmerged paths in your index.\n"
> > 
> > -			"Did you forget to use 'git add'?"));
> > +			"You might want to use 'git add' on them."));
> 
> [...]
> 
> >  		if (opts.new_branch && argc == 1)
> >  		
> >  			die(_("Cannot update paths and switch to branch '%s' at the same
> >  			time.\n"
> > 
> > -			      "Did you intend to checkout '%s' which can not be resolved 
as
> > commit?"), +			      "'%s' can not be resolved as commit, but it
> > should."),
> 
> In the current state I think this patch makes things worse (questions
> are not automatically a bad thing), which would make it especially
> useful to see more about the motivation so we can find out whether
> there's another way.
> 

I am not a UX designer, but for me, in the context of interaction with a 
command line program, any question that does not accept a reply is bad design. 
That also means that any command that does not run interactively should not 
ask questions. The shell interface is too informal to allow being loose on the 
program side. Comparatively to a GUI, where a label is formally informative 
and a popping-up dialog box asks for user input.

This patch should indeed be squashed with the first one. They are small changes 
in strings printed when dying.  They would share the more extended commit 
message.