* Why does git diff-index show intent-to-add file as "Added"?
@ 2020-10-17 16:21 Pratyush Yadav
2020-10-17 20:18 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Pratyush Yadav @ 2020-10-17 16:21 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
Hi,
I have been trying to wrap my head around intent-to-add files to add
support for them in git-gui and one point really confuses me.
Say I do:
$ git add -N foo
git-gui uses `git diff-index --cached HEAD` to find out the status of
the "staged changes" and `git diff-files` to find out the status of
"unstaged changes".
In this case, running diff-files gives:
:000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 A foo
which tells git-gui that the file is "added" thanks to the 'A'. Makes
sense. We can infer that the file in intent-to-add because untracked
files are not listed by diff-files.
Running diff-index gives:
:000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A foo
which tells git-gui that the file is added to the index thanks to the
'A'. This makes less sense. The file has not been staged yet so why
should it be listed as such?
This causes problems because we then end up showing the file in both the
"Unstaged Changes" and the "Staged Changes" sections, even though the
file has no staged changes at all. And `git status` says the same. It
only lists foo in unstaged changes.
In addition, this makes it much more complicated to determine if a file
marked as intent-to-add has some parts staged and some others unstaged.
To determine that, I have to look at what diff-files says about the
file. If it says 'A', then the file has no changes staged. If it says
'M' then it does. This means I have to look at the status of the
"unstaged changes" section to find out information about the "staged
changes" section. This makes it much harder to write clean, isolated
routines.
Is there something wrong with the mental model I'm using here? How does
git-status figure these things out? Or is it really a design mistake? If
so, what can we do to fix it?
--
Regards,
Pratyush Yadav
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why does git diff-index show intent-to-add file as "Added"?
2020-10-17 16:21 Why does git diff-index show intent-to-add file as "Added"? Pratyush Yadav
@ 2020-10-17 20:18 ` Junio C Hamano
2020-10-18 16:00 ` Phillip Wood
2020-10-27 12:09 ` Pratyush Yadav
0 siblings, 2 replies; 6+ messages in thread
From: Junio C Hamano @ 2020-10-17 20:18 UTC (permalink / raw)
To: Pratyush Yadav; +Cc: git, Johannes Schindelin
Pratyush Yadav <me@yadavpratyush.com> writes:
> In this case, running diff-files gives:
>
> :000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 A foo
Yes, it says "when comparing the index and the working tree, working
tree side has it, and the index side does not, so it is an addition".
Of course, if it is truly a new file that the index does not even
know about, we'd stay silent, but a path that are marked with i-t-a
bit is what the user told us to keey an eye on, so that is what you
would get.
> Running diff-index gives:
>
> :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A foo
If this is "diff-index HEAD", then I think it is expected. "when
comparing the HEAD and the working tree, working tree side has it,
and the tree side does not, so it is an addition." Exactly the same
story as "diff-files".
What should happen in "diff-index --cached HEAD", I offhand do not
know. "diff-index --cached HEAD" is a request to compare two trees,
i.e. the tree that _would_ be produced if you wrote the index out as
a tree (i.e. "git write-tree") right now, and the tree of HEAD. So
I think it may be sensible for the command to behave as if the i-t-a
path does not even exist in the index when it is run with "--cached";
I may be missing some subtleties that require us to do something
different, but that is what I would think.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why does git diff-index show intent-to-add file as "Added"?
2020-10-17 20:18 ` Junio C Hamano
@ 2020-10-18 16:00 ` Phillip Wood
2020-10-18 20:07 ` Junio C Hamano
2020-10-27 12:09 ` Pratyush Yadav
1 sibling, 1 reply; 6+ messages in thread
From: Phillip Wood @ 2020-10-18 16:00 UTC (permalink / raw)
To: Junio C Hamano, Pratyush Yadav; +Cc: git, Johannes Schindelin
On 17/10/2020 21:18, Junio C Hamano wrote:
> Pratyush Yadav <me@yadavpratyush.com> writes:
>
>> In this case, running diff-files gives:
>>
>> :000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 A foo
>
> Yes, it says "when comparing the index and the working tree, working
> tree side has it, and the index side does not, so it is an addition".
>
> Of course, if it is truly a new file that the index does not even
> know about, we'd stay silent, but a path that are marked with i-t-a
> bit is what the user told us to keey an eye on, so that is what you
> would get.
>
>> Running diff-index gives:
>>
>> :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A foo
>
> If this is "diff-index HEAD", then I think it is expected. "when
> comparing the HEAD and the working tree, working tree side has it,
> and the tree side does not, so it is an addition." Exactly the same
> story as "diff-files".
>
> What should happen in "diff-index --cached HEAD", I offhand do not
> know. "diff-index --cached HEAD" is a request to compare two trees,
> i.e. the tree that _would_ be produced if you wrote the index out as
> a tree (i.e. "git write-tree") right now, and the tree of HEAD. So
> I think it may be sensible for the command to behave as if the i-t-a
> path does not even exist in the index when it is run with "--cached";
> I may be missing some subtleties that require us to do something
> different, but that is what I would think.
If a user runs `add -N file` then if they run `git reset -p` (which runs
`git diff-index --cached HEAD`) it will ask them if they want to remove
`file` from the index. If `diff-index --cached` hid i-t-a entries we'd
lose that or have to get the i-t-a entries another way. Having said that
it does seem strange for `diff-index --cached` to be showing i-t-a
entries. Perhaps `diff-index --cached` should default to
--ita-invisible-in-index?
Best Wishes
Phillip
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why does git diff-index show intent-to-add file as "Added"?
2020-10-18 16:00 ` Phillip Wood
@ 2020-10-18 20:07 ` Junio C Hamano
0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2020-10-18 20:07 UTC (permalink / raw)
To: Phillip Wood; +Cc: Pratyush Yadav, git, Johannes Schindelin
Phillip Wood <phillip.wood123@gmail.com> writes:
>> I think it may be sensible for the command to behave as if the i-t-a
>> path does not even exist in the index when it is run with "--cached";
>> I may be missing some subtleties that require us to do something
>> different, but that is what I would think.
>
> If a user runs `add -N file` then if they run `git reset -p` (which
> runs `git diff-index --cached HEAD`) it will ask them if they want to
> remove `file` from the index. If `diff-index --cached` hid i-t-a
> entries we'd lose that or have to get the i-t-a entries another
> way. Having said that it does seem strange for `diff-index --cached`
> to be showing i-t-a entries. Perhaps `diff-index --cached` should
> default to --ita-invisible-in-index?
It probably is a good idea to consider if the implementation of `git
reset -p` is doing a sensible thing, or relying on a buggy behaviour
of "diff-index --cached" (worse yet, broken "diff-index --cached" to
suit its needs) and see if it can be written differently.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why does git diff-index show intent-to-add file as "Added"?
2020-10-17 20:18 ` Junio C Hamano
2020-10-18 16:00 ` Phillip Wood
@ 2020-10-27 12:09 ` Pratyush Yadav
2020-10-27 20:06 ` Junio C Hamano
1 sibling, 1 reply; 6+ messages in thread
From: Pratyush Yadav @ 2020-10-27 12:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
On 17/10/20 01:18PM, Junio C Hamano wrote:
> Pratyush Yadav <me@yadavpratyush.com> writes:
>
> > In this case, running diff-files gives:
> >
> > :000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 A foo
>
> Yes, it says "when comparing the index and the working tree, working
> tree side has it, and the index side does not, so it is an addition".
>
> Of course, if it is truly a new file that the index does not even
> know about, we'd stay silent, but a path that are marked with i-t-a
> bit is what the user told us to keey an eye on, so that is what you
> would get.
>
> > Running diff-index gives:
> >
> > :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A foo
>
> If this is "diff-index HEAD", then I think it is expected. "when
> comparing the HEAD and the working tree, working tree side has it,
> and the tree side does not, so it is an addition." Exactly the same
> story as "diff-files".
It is `git diff-index --cached HEAD`.
> What should happen in "diff-index --cached HEAD", I offhand do not
> know. "diff-index --cached HEAD" is a request to compare two trees,
> i.e. the tree that _would_ be produced if you wrote the index out as
> a tree (i.e. "git write-tree") right now, and the tree of HEAD. So
> I think it may be sensible for the command to behave as if the i-t-a
> path does not even exist in the index when it is run with "--cached";
> I may be missing some subtleties that require us to do something
> different, but that is what I would think.
This is what I think too. Can we then treat this as a bug, and work on
fixing it? Does any subsystem expert have any comments and/or provide
extra context?
--
Regards,
Pratyush Yadav
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why does git diff-index show intent-to-add file as "Added"?
2020-10-27 12:09 ` Pratyush Yadav
@ 2020-10-27 20:06 ` Junio C Hamano
0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2020-10-27 20:06 UTC (permalink / raw)
To: Pratyush Yadav; +Cc: git, Johannes Schindelin
Pratyush Yadav <me@yadavpratyush.com> writes:
> It is `git diff-index --cached HEAD`.
>
>> What should happen in "diff-index --cached HEAD", I offhand do not
>> know. "diff-index --cached HEAD" is a request to compare two trees,
>> i.e. the tree that _would_ be produced if you wrote the index out as
>> a tree (i.e. "git write-tree") right now, and the tree of HEAD. So
>> I think it may be sensible for the command to behave as if the i-t-a
>> path does not even exist in the index when it is run with "--cached";
>> I may be missing some subtleties that require us to do something
>> different, but that is what I would think.
>
> This is what I think too. Can we then treat this as a bug, and work on
> fixing it? Does any subsystem expert have any comments and/or provide
> extra context?
I do not think Phillip considers himself an expert in this area, but
what he pointed out in the thread
http://lore.kernel.org/git/xmqqo8kz70xv.fsf@gitster.c.googlers.com/
is worth listening to.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-10-27 20:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-17 16:21 Why does git diff-index show intent-to-add file as "Added"? Pratyush Yadav
2020-10-17 20:18 ` Junio C Hamano
2020-10-18 16:00 ` Phillip Wood
2020-10-18 20:07 ` Junio C Hamano
2020-10-27 12:09 ` Pratyush Yadav
2020-10-27 20:06 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).