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.
