Re: [PATCH] git-explain

Hi,

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

"J. Bruce Fields" [off-list ref] writes:

quoted

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

quoted

...

quoted

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

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

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;

... which is a good thing.

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

... which is also a good thing.

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

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

The last point [git-am refusing to run during a merge] can easily become 
a double-edged sword.

This particular behaviour seems like a good thing, too!

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