Re: [PATCH RFC] commit: allow to commit even if there are intent-to-add entries

[Junio C Hamano <gitster@pobox.com>]

Jonathan Nieder <jrnieder@gmail.com> writes:

>> When running "commit" and "status" with files marked with "intent to add",
>> I think there are three possible interpretations of what the user
>> wants to do.
> [ (1) thanks for stopping me, I had forgotten about that file;
>   (2) I changed my mind, please leave that file out; or (3) please
>   dwim and add the file ]
>
> I think (3) was a trick --- no one that does not use the "-a" option
> would want that. :)

I really wish it were the case, but I doubt it.

People from other VCS background seem to still think that "commit" without
paths should commit everything; after getting told that "what you add to
the index is what you will commit", I can easily see this commint: but but
but I told Git that I _want_ to add with -N! Why aren't you committing it?

> At the time, I did not understand what (2) meant.  Now I see why ---
> in interpretation (2), the user did not change her mind at all.

You are correct. "I still cannot make up my mind" is what is happening in
that situation.

The user explicitly said "I cannot decide about this path right now" when
she said "add -N". And we haven't heard from the user what should happen
to the path. Now we have to make a commit so somebody needs to decide.

> She
> said "I will be adding this file at some point, so please keep track
> of it along with the others for the sake of commands like 'git diff'
> and 'git add -u', but that does not mean "I will be adding this file
> at some point _before the next commit_".

Correct. She only said "I cannot decide right now" when she said "add -N"
and hasn't gave us any more hint as to what should happen now we have to
make a commit.

It is _wrong_ for us to unilaterally decide for the user that she does not
want the path in the commit. The last we heard from her was that she does
not know what should happen to the path.

> (2) makes intent-to-add entries just like any other tracked index
> entry with some un-added content.

You are comparing files edited in the working tree without the user
telling anything about them to Git (both tracked and untracked) and files
the user explicitly told Git that the user hasn't made up her mind
about. Why is it a good thing to make the latter behave "just like any
other"?