{"thread":{"id":"53943","subject":"Issue when adding new files to staged changes using interactive mode","startedAt":"2020-07-28T23:10:25Z","lastAt":"2020-07-31T19:51:19Z","messageCount":5,"participants":["Another Email","Raymond E. Pasco","Taylor Blau"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"402267","messageId":"5BDF4B85-7AC1-495F-85C3-D429E3E51106@gmail.com","threadId":"53943","inReplyTo":null,"subject":"Issue when adding new files to staged changes using interactive mode","fromName":"Another Email","fromEmail":"yetanotheroneemail@gmail.com","sentAt":"2020-07-28T23:10:19Z","receivedAt":"2020-07-28T23:10:25Z","isPatch":false,"sender":{"key":"yetanotheroneemail@gmail.com","avatar":null},"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\ngit init test\ncd test\necho \"test\" > test.txt\ngit add -AN\ngit add -p\n\nWhat did you expect to happen? (Expected behavior)\nThe file would be added to staged changes after confirming each individual change in an interactive mode.\n\nWhat happened instead? (Actual behavior)\nI get \"error: test.txt: already exists in index\".\n\nWhat's different between what you expected and what actually happened?\nThe file wasn't added to staged changes.\n\nAnything else you want to add:\nIt 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.\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.28.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: 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\ncompiler info: clang: 11.0.3 (clang-1103.0.32.62)\nlibc info: no libc information available\n$SHELL (typically, interactive shell): /bin/zsh\n\n\n[Enabled Hooks]\n\n"},{"id":"402365","messageId":"C4JC6LFSAFFS.2U4ZZ9ZMO066A@ziyou.local","threadId":"53943","inReplyTo":"5BDF4B85-7AC1-495F-85C3-D429E3E51106@gmail.com","subject":"Re: Issue when adding new files to staged changes using interactive mode","fromName":"Raymond E. Pasco","fromEmail":"ray@ameretat.dev","sentAt":"2020-07-29T18:58:09Z","receivedAt":"2020-07-29T20:18:35Z","isPatch":false,"sender":{"key":"ray@ameretat.dev","avatar":"https://avatars.githubusercontent.com/u/115765?v=4"},"body":"This is introduced in commit feea6946a5b746ff4ebf8ccdf959e303203a6011\n(diff-files: treat \"i-t-a\" files as \"not-in-index\"). I guess this leads\nto add-patch skipping directly to attempting to apply the hunk, rather\nthan trying to combine it with what's already in the index, and apply\n--check --cached correctly reports that it's already in the index.\n\nI'm looking at add-patch.c but it's not immediately obvious to me how it\nhandles already-staged changes, so I don't have a proposed patch.\n"},{"id":"402384","messageId":"C4JFF5L90V54.1FQKYQPIC3O43@ziyou.local","threadId":"53943","inReplyTo":"C4JC6LFSAFFS.2U4ZZ9ZMO066A@ziyou.local","subject":"Re: Issue when adding new files to staged changes using interactive mode","fromName":"Raymond E. Pasco","fromEmail":"ray@ameretat.dev","sentAt":"2020-07-29T21:30:23Z","receivedAt":"2020-07-29T21:40:19Z","isPatch":false,"sender":{"key":"ray@ameretat.dev","avatar":"https://avatars.githubusercontent.com/u/115765?v=4"},"body":"Before I continue rooting around in the source, though, I wonder if the\nreal issue here isn't the fact that add -p fails to support new files\n(requiring the intent-to-add workaround in the first place). I have\nalways thought it's a confusing user experience that git add -p on a\nfile that isn't yet tracked simply returns \"No changes\".\n\nThe underlying problem may be, and I say this without intimate knowledge\nof the subsystem, that we're now trying to force add-patch.c to do\nsomething it doesn't actually support, namely new files, whereas before\nit was attempting to patch what it saw as an empty file.\n\nThis (patch-adding new files) is real in my workflow; is there any\nreason why git add -p with an explicit argument shouldn't attempt to add\nuntracked files covered by the explicit argument? (In addition to fixing\nit for intent-to-adds.)\n"},{"id":"402396","messageId":"3B809D01-D744-436E-98A5-73B4BE6351CC@gmail.com","threadId":"53943","inReplyTo":"C4JFF5L90V54.1FQKYQPIC3O43@ziyou.local","subject":"Re: Issue when adding new files to staged changes using interactive mode","fromName":"Another Email","fromEmail":"yetanotheroneemail@gmail.com","sentAt":"2020-07-29T22:33:48Z","receivedAt":"2020-07-29T22:33:55Z","isPatch":false,"sender":{"key":"yetanotheroneemail@gmail.com","avatar":null},"body":"Hi Raymond,\n\nThanks for looking into this.\n\n> Before I continue rooting around in the source, though, I wonder if the\n> real issue here isn't the fact that add -p fails to support new files\n> (requiring the intent-to-add workaround in the first place). I have\n> always thought it's a confusing user experience that git add -p on a\n> file that isn't yet tracked simply returns \"No changes\".\n> \n> The underlying problem may be, and I say this without intimate knowledge\n> of the subsystem, that we're now trying to force add-patch.c to do\n> something it doesn't actually support, namely new files, whereas before\n> it was attempting to patch what it saw as an empty file.\n\nI 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.\n\n> \n> This (patch-adding new files) is real in my workflow; is there any\n> reason why git add -p with an explicit argument shouldn't attempt to add\n> untracked files covered by the explicit argument? (In addition to fixing\n> it for intent-to-adds.)\n\nIf 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.\n\n"},{"id":"402582","messageId":"20200731195114.GA3409@syl.lan","threadId":"53943","inReplyTo":"5BDF4B85-7AC1-495F-85C3-D429E3E51106@gmail.com","subject":"Re: Issue when adding new files to staged changes using interactive mode","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-07-31T19:51:14Z","receivedAt":"2020-07-31T19:51:19Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Jul 29, 2020 at 12:10:19AM +0100, Another Email wrote:\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n>\n> What did you do before the bug happened? (Steps to reproduce your issue)\n> git init test\n> cd test\n> echo \"test\" > test.txt\n> git add -AN\n\nPassing '-A' to 'git add' is the problem. See the discussion further\ndown in the thread for why this is the case. Whether or not this is a\ngood thing, this will do what you want without '-A' (that is, by running\n'git add -N' instead).\n\nThanks,\nTaylor\n"}]}