Re: [PATCH] git-explain

From: Junio C Hamano <junkio@cox.net>
Date: Dec 5, 2006, 06:09 UTC
Message-ID: <7v1wnekh6a.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20061205035721.GA26735@fieldses.org>

"J. Bruce Fields" <bfields@fieldses.org> writes:

Show 8 quoted lines

> On Mon, Dec 04, 2006 at 10:55:49PM -0500, Nicolas Pitre wrote:
>> ...
>> > [PATCH] git-explain
>> > ...
>> 
>> What about calling it git-whatsup instead?
>
> No, clearly it should be git-wtf.

Should I take these responses to mean that you two are negative about the approach of spending extra cycles to commands that can leave the working tree in a "in the middle of doing something" state to help having a unified command to explain what the situation is and suggest the user possible exits, or are you saying that it might be a good idea but "git explain" is a bad name?

An issue with this approach is that this can be the beginning of hardwiring the official "right way of doing things" in the set of tools. Pursuing this approach would enhance the set of state markers like "FAILED_MERGE" in the example, which means:

 - more commands would actively record what they were attempting
   to do, obviously;

 - over time "git explain" will learn about these state markers,
   and we would hardwire the "best current practice" exits from
   various states in the help messages;

 - also commands other than "git explain" would learn about the
   state markers of other commands, and change their behaviour.
   For example, "git am" might learn to refuse running while a
   merge in progress much earlier than with the current
   implementation.

The last point can easily become a double-edged sword.

Hardwiring the recommended workflow in the tools would reduce chances of mistakes, but it could rob the flexibility from them if we are not careful and forget to take into account some useful combination of tools when adding such safety valves.