Hi,

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

quoted text
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
> > 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 [...]

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

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

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

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

quoted text
> 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!

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html