Re: [PATCH] git-commit: revamp the git-commit semantics.

From: Nicolas Pitre <nico@cam.org>
Date: Feb 7, 2006, 16:59 UTC
Message-ID: <Pine.LNX.4.64.0602071135110.5397@localhost.localdomain>
In-Reply-To: <7voe1le71b.fsf@assigned-by-dhcp.cox.net>

On Sun, 5 Feb 2006, Junio C Hamano wrote:

Show 5 quoted lines

> I was hoping that, once people get used to --include and --only,
> they start to "revel in the index" (as Linus puts it), and
> realize that defaulting to --only is not such a good idea after
> all.  When that happens, I could leave --include as the
> default without getting complaints from them ;-).

I know this is like fighting old habits, but at some point one as to realize that there was a mistake in the interface and the best way to solve that mistake is to go with the objectively most intuitive solution.

People can get used to the index concept like you did yourself of course, but that is still dismissing the very reason for doing that change in the first place, which is that to a git beginner it is counter intuitive to have side effects when explicit paths are specified _alone_.

> The net effect, if we end up doing so, would be that we gained
> an extra flag --only that the user can use to explicitly ask for
> a partial commit when they want one, without disrupting the
> established workflow of old timers.

It is a bit deconcerting to see that git has already reached the software stone age and that so called "old timers" already have more weight than clean interfaces... even after less than a year.

Please don't make it another CVS and fix those inconsistencies clean and quick while the user base is not yet inapt to change.

Show 6 quoted lines

> The --only semantics is a useful thing in many situations, while
> the --include semantics is also a useful thing in many other
> cases.  The latter might be a better match to the way the git
> internal works, but both are equally useful options that support
> different workflows.  I do not see an inherent reason to declare
> one over the other to be "the default".

What has happened to the "least surprise" principle? That clearly favorize the former IMHO.

> So we could instead
> have no defaults at all (i.e. you have to explicitly say which
> kind you want if you use paths...).

And that would be just a nice usability annoyance.

Maybe being too intimate with git doesn't make it obvious to you, but if you do a survey of the number of tools that allows accepting a list of paths for their only arguments it should be pretty obvious that the vast majority operate only on those explicit paths without any hidden side effect.

If "git commit" is meant to be a user helper script to hide the low level git plumbing then it better do it with the least surprise principle in mind, otherwise it misses its very purpose. And the faster this is corrected the better, especially since this is not such a disturbing change after all.

Nicolas