On Fri, Nov 08, 2019 at 02:50:35PM -0800, Emily Shaffer wrote: > Is there a reason that git add -p can't do whole-file support this way? > While I'm less sure about what I'd like to see for copied files, I do > feel like there's a strong argument for patch adding new or deleted > files. I have been mildly annoyed by trying to "add -p" an untracked file before, too. But there is some complexity with broader pathspecs, I think. For instance, imagine I have a subdirectory in my repo with three files: - subdir/tracked -- this one is a real tracked file with modifications - subdir/new -- this is a new file I've just added - subdir/cruft -- this is some junk I wrote while debugging Then what should: git add -p subdir do? Obviously it should ask about "tracked". And we'd want it to do the "add -N" thing on "new", but not on "cruft". I don't mind being _asked_ about the "cruft" file if I can just say "n" to ignore it. But I wouldn't want it left in the index as intent-to-add. So just pretending that it was the same as: git add -N "$@" && git add -p "$@" seems poor. But it would be fine if instead we tentatively consider files matching the pathspec as tracked (assuming they're not .gitignored), and then the end result for each path is either that it has content staged by "-p", or it's left unchanged (including untracked if it was not previously tracked). I'm not sure when you intended for this to kick in. The case of "git add -p an-actual-file", where the pathspec matches exactly one file, is an obvious one. But because the shell expands wildcards, too, I don't know if it's a good heuristic for "the user really meant to mention this file". I.e., if I do: git add -p *.c Git will see individual filenames on the command-line, but the user may not have wanted to include all of them. There's also a question of what "git add -p" without any pathspecs should do. I'd think you would probably want no change from the current behavior (i.e., not even asking about untracked files). -Peff
