Re: [PATCH 2/4] commit: introduce a config key to allow as-is commit with i-t-a entries

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 6, 2012, 19:50 UTC
Message-ID: <7vhaz37nce.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1328525855-2547-3-git-send-email-pclouds@gmail.com>

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

Show 9 quoted lines

> +commit.ignoreIntentToAdd::
> +	Allow to commit the index as-is even if there are
> +	intent-to-add entries (see option `-N` in linkgit:git-add[1])
> +	in index. Set to `false` to disallow commit in this acase, or `true`
> +	to allow it.
> ++
> +By default, `git commit` refuses to commit as-is when you have intent-to-add
> +entries. This will change in 1.8.0, where `git commit` allows it. If you
> +prefer current behavior, please set it to `false`.

s/acase/case/;

More importantly, if we allow it, what would be included and what would be omitted from the final commit? What happens if we allow it is much more important information than "we allow it even if there are".

	When set to `true`, prevent `git commit` from creating a commit
	from an index that has entries that were added with `git add -N`
	but have not been updated with real contents, as the user may have
	forgotten to tell the final contents for these entries.  Setting
	this to `false` makes `git commit` pretend as if these entries do
	not exist in the index.

	The default for this variable is `false`, but it will change to
	`true` in later releases of git (perhaps 1.8.0). To ease the
	transition, you may want to set it to `true` now and get used to
	the new behaviour early, or you may want to set it to `false` to
	keep the old behaviour a bit longer. We however expect to support
	setting this to `false` (to keep the current behaviour) only for a
	limited time after the default is changed to `true`.

Now, I removed the "intent to add" jargon from the above paragraph, the description below can lose it as well.

Show 17 quoted lines

> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index 9c1d395..ec548ea 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -123,8 +123,16 @@ subdirectories.
>  	Record only the fact that the path will be added later. An entry
>  	for the path is placed in the index with no content. This is
>  	useful for, among other things, showing the unstaged content of
> -	such files with `git diff` and committing them with `git commit
> -	-a`.
> +	such files with `git diff`.
> ++
> +Paths added with this option have intent-to-add flag in index. The
> +flag is removed once real content is added or updated. By default you
> +cannot commit the index as-is from until this flag is removed from all
> +entries (i.e. all entries have real content). See commit.ignoreIntentToAdd
> +regardless the flag.

I cannot understand "regardlessthe flag" in the last sentence.

> ++
> +Committing with `git commit -a` or with selected paths works
> +regardless the config key and the flag.

Just an aside, not suggesting to change anything to the final text.

This is interesting in that the reason why "selected paths" works is a bit subtle. You may have entries added with `-N` that are covered by the pathspec, and those that are not covered by the pathspec. For the former (i.e. those the user said "I'll decide the final contents later" but are covered by pathspec), the user is telling the final contents to be in the commit, so we know the final contents for them. For the latter (i.e. those outside the pathspec), they are excluded and made to match the version in the HEAD commit, so we know the final contents for them, too.

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

Can we phrase this a bit better?

It is not like "forbids", but is "giving up because you didn't tell me what content to include in the commit, even though you said you will tell me later".