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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> 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.
> ++
> +Committing with `git commit -a` or with selected paths works
> +regardless the config key and the flag.

It still is not clear to me how best to sell this change to the end-user
community.

IIRC, the original motivation of intent-to-add "add -N" was in response to
users who curse Git because they often forget to add new files before
committing, and they wanted to say "Here I have a new file, it is not
complete yet, but I do not want it left out of the commit. While my memory
is fresh, let me tell Git to keep an eye on it, so that it can remind me
if I forget to add the final contents."  For them, the current "did you
forget to add them?  If so tell me the final contents for at least the
paths you will be changing with this commit" error was a perfect safety
solution.

It turned out that the benefits described we see above in the context,
"This is useful, among other things, ...", were of more value, and for
these use cases, i-t-a entries ceased to mean "I may forget, so I am
telling you now, please remind me when I say commit."  And "did you
forget?" error is hinderance for them.

But does that mean nobody will ever need "please remind me lest I forget"?
Just the original requestor of the "add -N" feature may still be using
git, but more importantly, isn't it the case that those who have been
using it merely for the other side effect (e.g. 'git diff') sometimes want
the "please remind me" safety?

I suspect that some among 1 million Git users would want the "please
remind me", so a solution with configuration variable without command line
override is not ideal (command line without any configurability is fine as
long as we have a good default).

I am beginning to think "safety by default, which can be turned off by
learned users, but still can be turned on on demand" may be a lot easier
to sell this.  That is:

 - commit.ignoreIntentToAdd defaults to `false`; the default will never
   change.  The users can set it to `true`.

 - "commit --ignore-intent-to-add" can be used without setting the
   configuration or to defeat an explicit `false`, for a one-shot request.

 - "commit --honor-intent-to-add" can be used to defeat an explicit
   `true`, for a one-shot request.

The third one is a bit funny, as it is a way to bring back safety when the
user earlier decided that he does not need that kind of safety (i.e. "I
only say 'add -N' for `diff` and stuff, I will never forget to add real
contents before committing"), so it will almost never be used, because
these users who set 'ignoreIntentToAdd = true' do _not_ expect Git to help
them in remembering to add the real contents.  And having to add a funny
option just for the sake of completeness is often an indication that there
is something fundamentally wrong in the system that the option tries to
express an interface into it.

Without conclusion... Sigh...
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]