From: Jacob Keller Date: Thu, 20 Oct 2016 17:27:58 GMT Subject: Re: tools for easily "uncommitting" parts of a patch I just commited? Message-ID: In-Reply-To: On Thu, Oct 20, 2016 at 9:30 AM, Junio C Hamano wrote: > Jeff King 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 " 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 " 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 > already added to the index when I do so, i.e. an unrelated small > typofix in 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 . 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 " I want git commit to complain here that the index and acutal 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 into the index, and then run git commit Does that make sense? Basically if the index and "git commit " both say "add " but they conflict in what version of I want it to go "hey.. uhhh.. that's a bad idea" Thanks, Jake