Jacob Keller <jacob.keller@xxxxxxxxx> writes: >> I am not sure if that is OK. I think it is less not-OK than the use >> case I mentioned in my earlier message, in that this is not a case >> that "please don't do it" breaks. It however is an inconvenience >> that the user has to say "git add file" before the "git commit" (or >> "git commit file") to conclude the sequence. >> >> So I dunno. > > Hmmm.. Ya ok I don't think we can actually distinguish between these > two work flows. What we might want to have in "git commit <paths>" is a new mode that is totally different from -i/-o that says roughly "Start from the tree of HEAD, pretend as if you removed all the paths that match the given pathspec from the tree, and then added all the entries in the index that match that pathspec. Write that tree and commit. Take nothing from the working tree". I have a feeling that when people do $ git add -p file1 file2 file3 $ git commit file2 and ends up including _all_ changes made to file2, not just the ones they picked in the earlier part of the workflow, they are expecting such a behaviour.