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

From: Jon Loeliger <jdl@freescale.com>
Date: Feb 7, 2006, 19:25 UTC
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:

Show 17 quoted lines

> 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