git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Pratyush Yadav <me@yadavpratyush.com>
To: git@vger.kernel.org
Cc: Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Why does git diff-index show intent-to-add file as "Added"?
Date: Sat, 17 Oct 2020 21:51:11 +0530	[thread overview]
Message-ID: <20201017162111.gvisfz2daqvhnjmb@yadavpratyush.com> (raw)

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

             reply	other threads:[~2020-10-17 16:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-17 16:21 Pratyush Yadav [this message]
2020-10-17 20:18 ` Why does git diff-index show intent-to-add file as "Added"? 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201017162111.gvisfz2daqvhnjmb@yadavpratyush.com \
    --to=me@yadavpratyush.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).