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

[Nicolas Pitre <nico@cam.org>]

On Tue, 7 Feb 2006, Junio C Hamano wrote:

> That is this '--only/--include are available but currently the
> traditional --include is the default' is all about.  It is about
> not breaking current users during transition.  And People's
> Scripts.  If a tool wants traditional semantics, it can hardcode
> "--include" (or --only if not), and does not have to worry about
> the default getting switched "some day".

I'm completely with you here.  However is there so many tools that 
relies on the current behavior of "git commit"?

> Once things are prepared that way, we can switch the default any
> day, as long as we give users enough advance notice.

Good.  It just seemed to me that you weren't convinced that any default 
switching was needed.  Sorry if I misread you.

What prompted my initial reply to you was this:

|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".  So we could instead
|have no defaults at all (i.e. you have to explicitly say which
|kind you want if you use paths...).

to which I disagreed.

> It is possible that you are well aware of all of the above, and
> are arguing that "enough advance notice" period should be zero
> days.  But I don't think that is nice.

Certainly not zero days.  I'm just trying to counter-balance the 
"without disrupting the established workflow of old timers" argument 
which is the worst enemy of healthy software evolution.  If such an 
argument was to prevail in the Linux world then we would have had those 
evil "stable driver ABI" for a long time already.  If that argument was 
to prevail for git then that would be the beginning of its stagnation.

As for the advance notice, it might be a good idea to simply switch the 
default in 1.3.0 giving any script author relying on the --include 
behavior (if any) proper insentive to fix them. The 1.3.x branch being 
the so called "unstable" branch makes it the appropriate place to do 
it at the earliest, providing script authors enough time to test their 
modifications on the real thing before it becomes official 1.4.0.

But you should consider all above rambling as part of the feedback you 
asked for.  I don't pretend to always be right.


Nicolas