On Wed, Oct 19, 2016 at 7:13 PM, Jeff King <p...@peff.net> wrote: > I suspect both of those would complain about legitimate workflows. > > I dunno. I do not ever use "git commit <file>" myself. I almost > invariably use one of "git add -p" (to review changes as I add them) or > "git add -u" (when I know everything is in good shape, such as after > merge resolution; I'll sometimes just "git commit -a", too). > > But it sounds like you want a third mode besides "--include" and > "--only". Basically "commit what has been staged already, but restrict > the commit to the paths I mentioned". Something like "--only-staged" or > something. I do not think we would want to change the default from > --only, but I could see a config option or something to select that > behavior. > > I suspect nobody has really asked for such a thing before because > separate staging and "git commit <file>" are really two distinct > workflows. Your pain comes from mix-and-matching them. > > -Peff
No. What I want is to *prevent* mix-and-match from happening. Basically, sometimes I use "git add -p" to stage changes. But if I just did a "git diff" and I know all the changes that I want are in the file I will just do "git commit <file>" or "git commit -a". The problem is that sometimes I stage stuff, forget or just make a brain mistake, and I go ahead and use "git commit <file>" What I want is to make it so that when you run "git commit <file>" that it is smart enough to go "hey! You already staged something from that file in the index and it doesn't match what you're asking me to commit now, so I'm going to stop and make sure you either reset, don't run "git commit <file>" or run "git commit --only <file>" or similar. It's just about making it so that if I happen to make the mistake in the future it doesn't generate a commit and instead tells me that I was being an idiot. I don't want this check to just be "you can't stage with the index and then tell me to commit -a or commit <files>" because I think that's too restrictive and might make people complain. Essentially, I want the tool to become smart enough to make it so that an obvious mistake is caught early before I have to undo things. That being said, it's much less of a pain point now that I know I can go "git reset -p HEAD^". It never occurred to me that git reset -p would work that way, so I didn't even try it. Thanks, Jake
