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

From: Junio C Hamano <junkio@cox.net>
Date: Feb 5, 2006, 23:10 UTC
Message-ID: <7voe1le71b.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <43E67745.2080302@gmail.com>

Marco Costalba <mcostalba@gmail.com> writes:

Show 5 quoted lines

> Because when, at last, you will switch the default to
> '--only', this option could be removed. So it's a temporary
> option with, peraphs, a temporary documentation, and a
> temporary user training to use it: IMHO has a meaning if the
> transition period is long enough.

Hmph, actually I was planning to leave --only in forever if we go that route. Peoples' scripts would need to explicitly ask for --only during the transition if they want that semantics, and removing that support afterwards would mean they would then need to remove --only from their scripts again.

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 ;-).

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.

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...).