Issue when adding new files to staged changes using interactive mode

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue) git init test cd test echo "test" > test.txt git add -AN git add -p

What did you expect to happen? (Expected behavior) The file would be added to staged changes after confirming each individual change in an interactive mode.

What happened instead? (Actual behavior) I get "error: test.txt: already exists in index".

What's different between what you expected and what actually happened? The file wasn't added to staged changes.

Anything else you want to add: It used to work before updating to 2.28, previous version was 2.26 if I'm not mistaken. I couldn’t find any mention of changes in the recent release notes.

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.28.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Darwin 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64 compiler info: clang: 11.0.3 (clang-1103.0.32.62) libc info: no libc information available $SHELL (typically, interactive shell): /bin/zsh

[Enabled Hooks]

This is introduced in commit feea6946a5b746ff4ebf8ccdf959e303203a6011 (diff-files: treat "i-t-a" files as "not-in-index"). I guess this leads to add-patch skipping directly to attempting to apply the hunk, rather than trying to combine it with what's already in the index, and apply --check --cached correctly reports that it's already in the index.

I'm looking at add-patch.c but it's not immediately obvious to me how it handles already-staged changes, so I don't have a proposed patch.

Before I continue rooting around in the source, though, I wonder if the real issue here isn't the fact that add -p fails to support new files (requiring the intent-to-add workaround in the first place). I have always thought it's a confusing user experience that git add -p on a file that isn't yet tracked simply returns "No changes".

The underlying problem may be, and I say this without intimate knowledge of the subsystem, that we're now trying to force add-patch.c to do something it doesn't actually support, namely new files, whereas before it was attempting to patch what it saw as an empty file.

This (patch-adding new files) is real in my workflow; is there any reason why git add -p with an explicit argument shouldn't attempt to add untracked files covered by the explicit argument? (In addition to fixing it for intent-to-adds.)

Hi Raymond,

Thanks for looking into this.

I cannot comment on the internals of git, but the typical use-case for using git add -p on new files would be when you add them as part of the changes that also involve existing files in the interactive mode, therefore it's helpful to have support for both compared to having to stage new files separately.

If I get the question right, it's perfectly fine for me personally to stage a single new file via git add -p. I agree, technically, it doesn't make a lot of sense, probably rather a matter of muscle memory, when you treat new files the same way as existing ones.

On Wed, Jul 29, 2020 at 12:10:19AM +0100, Another Email wrote:

Passing '-A' to 'git add' is the problem. See the discussion further down in the thread for why this is the case. Whether or not this is a good thing, this will do what you want without '-A' (that is, by running 'git add -N' instead).

Thanks, Taylor