From: Junio C Hamano Date: Tue, 07 Feb 2006 18:18:17 GMT Subject: Re: [PATCH] git-commit: revamp the git-commit semantics. Message-ID: <7vpslzuj6e.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <7vfymvvz1r.fsf@assigned-by-dhcp.cox.net> Junio C Hamano writes: > I was hoping that before 1.2.0 I can take a final "just in case" > quick poll to see everybody agrees making --only the default is > the way to go, then state it clearly that 1.3.0 will have the > default switched to --only in the release announcement. Clarification. Here is what I want to do. I've said enough times that we _may_ switch the default from traditional --include semantics to new --only semantics. Nico already even objected to the "may" part, and I am hoping it is shared by everybody on the list that "may" should be "will soon". Unless somebody comes up with a convincing argument otherwise, I'll write "this will switch to --only by the time 1.3.0 release is made, so start converting your scripts to explicitly say --include or --only if you want a specific behaviour, and start training your fingers in the meantime as well" in the 1.2.0 announcement, probably done sometime late this week. 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.