On Thu, Oct 20, 2016 at 11:41 AM, Junio C Hamano <[email protected]> wrote: > Jacob Keller <[email protected]> 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. >
Right now I think people who use it intentionally do expect it to work that way. I just happen to not have wanted to add <file> but did so anyways without considering, and thus I ended up including changes that were for the next commit. As long as there is a way to change "git commit" default from that mode then we could make the default work and then let people configure it to what makes sense. I'll take a look at going this route. Thanks, Jake
