Re: [PATCH 2/2] commit, write-tree: allow to ignore CE_INTENT_TO_ADD while writing trees

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 16, 2012, 23:21 UTC
Message-ID: <7vaa5nutbp.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1326681407-6344-3-git-send-email-pclouds@gmail.com>

Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:

> Normally cache-tree will not produce trees from an index that has
> CE_INTENT_TO_ADD entries. This is a safe measure to avoid
> mis-interpreting user's intention regarding this flag.

s/safe/safety/;

> There are situations however where users want to create trees/commits
> regardless i-t-a entries.

A new command line option "--no-check-intent-to-add" to "commit" without any configuration bit may be a useful addition as a first cut, and in order to help users to which "there are situations" is more than 50% of the time, a configuration that can be overriden by "--check-intent-to-add" may be a usability improvement over that first cut, but if this is really about "there are situations", then a configuration that cannot be overriden by command line option feels a wrong way to go about it.

Is this really about "there are situations" to begin with? I am suspecting that this patch is either:

 (1) making it easier to use a wrong workflow, by promoting a way to
     bypass a useful safety measure;

 (2) fixing an earlier UI mistake (iow, the interpretation #2 in the old
     discussion is always the right one and the existing safety measure is
     misguided) in such a way that allows you to work around an objection
     from a bonehead maintainer who refuses to admit that earlier mistake;
     and/or

 (3) splitting the Git userbase into two and making the resulting system
     harder to teach.

If it is (2), and I suspect it may be the case, we might want to rather honestly describe that the future direction is to fix it, and describe the configuration option as "an early opt-in" switch, together with the usual three-step deprecation and migration schedule to make the new behaviour the default in a future version. From the timeline point of view, it probably can coincide with the change to always start an editor when recording a merge commit.

In any case, for this change to help people who add more than one paths with "add -N" and want to include only a subset of them in the commit, we may want to explicitly teach them to add what they want to before committing with the new command line option in the documentation.