On Thu, Oct 20, 2016 at 9:30 AM, Junio C Hamano <gits...@pobox.com> wrote: > Jeff King <p...@peff.net> writes: > >>> I still think it's worth while to add a check for git-commit which >>> does something like check when we say "git commit <files>" and if the >>> index already has those files marked as being changed, compare them >>> with the current contents of the file as in the checkout and quick >>> saying "please don't do that" so as to avoid the problem in the first >>> place. >> ... >> I suspect both of those would complain about legitimate workflows. >> >> I dunno. I do not ever use "git commit <file>" myself. > > Users are different. I do use this all the time, and it is not > unusual at all to have changed contents on paths other than <file> > already added to the index when I do so, i.e. an unrelated small > typofix in <file> jumping ahead of the real changes I am working on > in other parts of the tree. > > "Please don't do that" would break. Jacob says "avoid the problem", > but I do not see a problem in allowing it (it could be that the > problem Jacob has is in other parts of his workflow, but I do not > know what it is offhand).
I still think we're misunderstanding. I want git commit to complain *only* under the following circumstance: I run "git add -p" and put a partial change into the index in <file>. There are still other parts which were not added to the index yet. Thus, the index version of the file and the actual file differ. Then, I (accidentally) run "git commit <file>" I want git commit to complain here that the index <file> and acutal <file> being requested are different and it thinks there's an issue. I do *NOT* want it to complain if I do "git add -p" and put parts of <other-file> into the index, and then run git commit <file> Does that make sense? Basically if the index and "git commit <file>" both say "add <file>" but they conflict in what version of <file> I want it to go "hey.. uhhh.. that's a bad idea" Thanks, Jake
