Re: [PATCH v2 2/2] Porcelain scripts: Rewrite cryptic "needs update" error message

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 3, 2010, 23:34 UTC
Message-ID: <7vhbh2etqo.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20101001051426.GF20098@kytes>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> This is one of the concerns I had while creating this iteration. What
> do you suggest? Should we limit the number of paths listed like this?

Personally, I do not think you should list any paths. If the program states clearly that it does not like to see a dirty working tree (or a dirty working tree is likely to be a mistake by a forgetful user), the user already has enough tools such as "git status" and "git diff" to figure out which ones are dirty.

> - If it's an "edit", "squash" or "fixup" interactive rebase step, the
>   staged changes are automatically committed to the current commit:
>   you don't have to explicity commit --amend.

It might be somewhat irritating to see "you haven't committed the amend" against "rebase --continue" after running "git add" or "git add -p" to shape what should be the final commit, and that is why the codepath runs "commit --amend" for the user, but I personally think this is an attempt to help users that is ill-thought-out. The codepath stops when there are changes to the working tree files that are not added, to avoid mistakes by a forgetful user, but what if the change the user forgot to add was an addition of a new file?

Also, this is one special case that the user has to remember.

It is too late to change this now, but it would have been a lot nicer if we insisted that the "commit --amend" is always done by the user, and never automatically by "rebase-i --continue" codepath.

> - If it's a "reword" step, staged changes/ dirty working tree don't
>   mean anything. The use should simply stash everything and continue
>   in this case.

Why would "reword" involve _any_ local changes?

> I suppose I can come up with a way to check which path was taken and
> print more targeted advice. Will do in the next iteration.

In general, I am mildly against giving advices like "commit or stash", especially when the program does not know the workflow the end user in each situation is using better than the end user.