Re: [PATCH] git-explain

From: Jeff King <peff@peff.net>
Date: Dec 5, 2006, 07:26 UTC
Message-ID: <20061205072622.GA21839@coredump.intra.peff.net>
In-Reply-To: <7v1wnekh6a.fsf@assigned-by-dhcp.cox.net>

On Mon, Dec 04, 2006 at 10:09:17PM -0800, Junio C Hamano wrote:

Show 7 quoted lines

> 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?

It seems like the point of this command is to show some state information which would otherwise be hard to see. I think of 'git status' as the way to look at the repository state. Perhaps we should enhance the output of 'git status' to note things such as failed merges, whether we're bisecting, in the middle of applying a patch series, etc. There could be an optional verbosity switch to give "full explanations" including recommended ways to deal with the situation.

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

As long as the safety valves don't come up _routinely_ in certain workflows, it seems OK to bypass them with a '-f' force switch. I suspect the best way to figure out if such workflows are in use is to put in the safety valves and see who complains; otherwise we're stuck with brainstorming workflows and deciding whether they make sense.