"D. Ben Knoble" <ben.knoble@xxxxxxxxx> writes:
>> >> * "git status" on intent-to-add index entries (say "I" in the first
>> >> column instead of "A" for short status, add "(needs 'git add')" at the
>> >> end of "new file: $path " in long status).
>> >
>> > I am interpreting this todo message as meaning that the following behavior
>> > should be implemented:
>>
>> I think that was done long time ago. The entry may have been a wish-item
>> in April 2011, but not anymore.
>
> At least in 2.48.1 and in git version 2.50.0.rc0.48.g74dbe4346c, this
> behavior isn't present. So I wouldn't call it "done"—maybe there was a
> discussion that it shouldn't be done, though? I didn't search the
> list.
I didn't either, so this response may not be adding much value, but
I think the intent of the above entry is so that the output allows
users to tell between already added entries and about to be added
entries. Perhaps in an ancient version of "git status" did not give
enough information to allow us to tell the status of the index entry
for the path and the status of the working tree file for the path
separately, or something?
In any case, we do not need to add anything to achieve that today.
$ >P
$ cp P Q
$ git add -N P
$ git add Q
The user expresses an intent to add P and actually adds Q.
$ git status -suno
A P
A Q
The first column of the output is about how the path in the index
compares with the HEAD, and the second column is about how working
tree file compares with the index. A file that hasn't been added
(e.g., untracked cruft) is not even known to the index so the latter
is _usually_ only for tracked files. The fact that P appears as
"_A" is a sign enough that its contents haven't been added to the
index, but only that the index has been made aware of the presence
of the path, which is exactly what intent-to-add is about.
If you further add P, this time for real, the status would become
"A_" (i.e. to the index, new contents added relative to HEAD; to the
working tree there is no change relative to the index), but the
intent-to-add bit is gone once the index has (a version of) contents
for the path P.
Normal output without "-s" is even easier to reason about.
$ git status -uno
On branch foo
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: Q
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
new file: P
P is _known_ to the system but its contents is not added at all, so
it is "not staged for commit", and known as a "new" file.
