Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes:
> - if (!set_commit_ignoreintenttoadd) {
Now no warning() is associated with testing of this flag, which means that
people who didn't get around to read the doc and react to the warnings in
the earlier releases will get _nothing_ when the real change hits them?
That sounds strangely bad. What am I missing?
> + if (!(cache_tree_flags & WRITE_TREE_IGNORE_INTENT_TO_ADD)) {
> int i;
> for (i = 0; i < active_nr; i++)
> if (active_cache[i]->ce_flags & CE_INTENT_TO_ADD)
> break;
> if (i < active_nr)
> warning(_("You are committing as-is with intent-to-add entries as the result of\n"
> - "\"git add -N\". Git currently forbids this case. This will change in\n"
> - "1.8.0 where intent-to-add entries are simply ignored when committing\n"
> - "as-is. Please look up document and set commit.ignoreIntentToAdd\n"
> - "properly to stop this warning."));
> + "\"git add -N\". Git currently forbids this case. But this is deprecated\n"
> + "support for this behavior will be dropped in FIXME.\n"
> + "Please look up document and set commit.ignoreIntentToAdd to true\n"
> + "or remove it."));
As this is marked with FIXME ;-)
At this point in the deprecation cycle, "currently forbids this case." is
not true at all. "You asked me to punt when you forgot to tell me the
final contents for i-t-a entries, so I am honoring your wish" is what is
happening here. Perhaps...
Git currently allows you to set commit.ignoreIntentToAdd to false
to remind you about the paths you may have forgotten to add the
real contents to before committing, but this support will be
removed in future versions of Git. Set commit.ignoreIntentToAdd
to `false` or remove the variable, and get used to the new
behaviour, to squelch this message.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html