patchRE: [PATCH] git-explain

On Mon, 4 Dec 2006, Junio C Hamano wrote:

What about calling it git-whatsup instead?

On Mon, Dec 04, 2006 at 10:55:49PM -0500, Nicolas Pitre wrote:

No, clearly it should be git-wtf.

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

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.

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

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.

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.

Hi,

On Mon, 4 Dec 2006, Junio C Hamano wrote:

I think they just were in the mood for some slashdot style unimportant-aspects-in-a-funny-way discussion.

... which is a good thing.

... which is also a good thing.

If the other commands are outside of git, it will be a problem.

This particular behaviour seems like a good thing, too!

As has been the case not at all long ago, a saftey valve which no longer made sense was just removed.

As for the inflexibility of a recommended workflow: by now, long-time gitsters have had enough time to fiddle around with git and to develop a workflow which Just Works. It is just a nice gesture of old-time users towards new-time users to pass that knowledge. And new-time users are often not in the least interested in learning the ropes the hard way.

Besides, the recommended workflow(s) can be changed/replaced by other porcelainish commands, because only those will contain the safety valves, right?

Ciao, Dscho

On Tue, Dec 05, 2006 at 09:58:25AM +0100, Johannes Schindelin wrote:

Yeah, I was just being silly, apologies.

Wouldn't it be better to create some kind of action-log (that's cleared at the end of the command if everything was all right) instead of creating special markers for different commands?

That way there would be only 1 place to check for what happened ...