git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* Issue when adding new files to staged changes using interactive mode
@ 2020-07-28 23:10 Another Email
  2020-07-29 18:58 ` Raymond E. Pasco
  2020-07-31 19:51 ` Taylor Blau
  0 siblings, 2 replies; 5+ messages in thread
From: Another Email @ 2020-07-28 23:10 UTC (permalink / raw)
  To: git

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]


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Issue when adding new files to staged changes using interactive mode
  2020-07-28 23:10 Issue when adding new files to staged changes using interactive mode Another Email
@ 2020-07-29 18:58 ` Raymond E. Pasco
  2020-07-29 21:30   ` Raymond E. Pasco
  2020-07-31 19:51 ` Taylor Blau
  1 sibling, 1 reply; 5+ messages in thread
From: Raymond E. Pasco @ 2020-07-29 18:58 UTC (permalink / raw)
  To: Another Email, git

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Issue when adding new files to staged changes using interactive mode
  2020-07-29 18:58 ` Raymond E. Pasco
@ 2020-07-29 21:30   ` Raymond E. Pasco
  2020-07-29 22:33     ` Another Email
  0 siblings, 1 reply; 5+ messages in thread
From: Raymond E. Pasco @ 2020-07-29 21:30 UTC (permalink / raw)
  To: Raymond E. Pasco, Another Email, git

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.)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Issue when adding new files to staged changes using interactive mode
  2020-07-29 21:30   ` Raymond E. Pasco
@ 2020-07-29 22:33     ` Another Email
  0 siblings, 0 replies; 5+ messages in thread
From: Another Email @ 2020-07-29 22:33 UTC (permalink / raw)
  To: Raymond E. Pasco; +Cc: git

Hi Raymond,

Thanks for looking into this.

> 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.

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.

> 
> 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.)

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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Issue when adding new files to staged changes using interactive mode
  2020-07-28 23:10 Issue when adding new files to staged changes using interactive mode Another Email
  2020-07-29 18:58 ` Raymond E. Pasco
@ 2020-07-31 19:51 ` Taylor Blau
  1 sibling, 0 replies; 5+ messages in thread
From: Taylor Blau @ 2020-07-31 19:51 UTC (permalink / raw)
  To: Another Email; +Cc: git

On Wed, Jul 29, 2020 at 12:10:19AM +0100, Another Email wrote:
> 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

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-28 23:10 Issue when adding new files to staged changes using interactive mode Another Email
2020-07-29 18:58 ` Raymond E. Pasco
2020-07-29 21:30   ` Raymond E. Pasco
2020-07-29 22:33     ` Another Email
2020-07-31 19:51 ` Taylor Blau

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git