From: Jon Loeliger <jdl@freescale.com>
Date: Tue, 07 Feb 2006 19:25:02 GMT
Subject: Re: [PATCH] git-commit: revamp the git-commit semantics.
Message-ID: <1139340302.13067.42.camel@cashmere.sps.mot.com>
In-Reply-To: <7vpslzuj6e.fsf@assigned-by-dhcp.cox.net>

On Tue, 2006-02-07 at 12:18, Junio C Hamano wrote:

> That means 1.2.0 (and its maintenance series 1.2.X) will ship
> with --include semantics for "git commit paths...", and will
> allow explicit --only/--include.  After 1.2.0, at some point,
> the "master" branch will start shipping with --only semantics as
> default.  No script should break when 1.3.0 happens.
> 
> People who want to use --include semantics will acquire a habit
> of explicitly askign for --include during 1.3.0 development
> period.  They do not need to unlearn anything when 1.3.0 happens.
> 
> People who learned to type --only can unlearn it to reduce
> typing when 1.3.0 happens, but unlearning is not a requirement.
> Being explicit should always work.
> 
> New people that come after 1.3.0 will get the --only semantics
> by default, the intuitiveness of which has been argued to death,
> without using any flags.

Hmmm...  So maybe just to add fire to the discussion,
maybe the problem lies in the "tool name".  What if there
were two tools named "git-commit-index" and "git-commit-path"?
I understand that this is, in some way, identical to the
"--include" and "--only" sorts of notions.  But I think it
might make the intent clearer, and easier to describe/document.
I think part of my concern with the options is trying to
recall/describe just exactly _what_ is "included" with
the "--include", or what is excluded with the "--only".
It is the index's data/state, of course.  So perhaps
a "git commit-index" might be consistent tool naming?
And for contrast "git commit-file" or "git commit-path"?

Just a thought.

jdl