Nguyễn Thái Ngọc Duy [off-list ref] 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.
2012/1/17 Junio C Hamano [off-list ref]:
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.
"git -c key=value commit" may help.
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.
This patch is towards (3). I agree that "add -N" can be confusing to
new users because it does not actually add anything. Those who do not
read manual carefully and commit without checking the result may fall
into that trap. So a user is expected to "level up" a bit and
hopefully by the time he/she feels the need to get around the safety
check and discover this flag, they should be ready to go without the
safety check.
Although I would not oppose deprecating the old behavior if you go with (2) ;)
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.
yeah, keep telling people "this does not add any thing, you need to
git-add again without -N" after running "add -N" using advice
framework when this config is on?
--
Duy
Nguyen Thai Ngoc Duy wrote:
Although I would not oppose deprecating the old behavior if you go with (2) ;)
My reaction on reading the patch and clarifying followup was similar
to Junio's. I don't think a configuration item makes sense unless we
are planning to flip the default in the future, and it would probably
be clearer to document it that way.
By the way, thanks very much for working on this. I wish I had more
time to offer more than comments.
Sincerely,
Jonathan