Re: 'commit -a' safety
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 25, 2010, 01:13 UTC
- Message-ID
- <7voch8mj04.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20100424164247.GM3563@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
Show 6 quoted lines
> On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote: >> El 24/04/2010, a las 11:40, Jakub Narebski escribió: >> > I'd like for 'git commit -a' to *fail* if there are staged changes for >> > tracked files, excluding added, removed and renamed files. > > Thanks for this suggestion, this is exactly what I wanted to propose!
I am somewhat torn.
I have made mistake of running "commit -a" after I spent time sifting my changes in the work tree. I can see that I would have been helped by it if the safety were there.
But at the same time, I also know that my development is often a cycle of change then diff then add (to mark the part I am happy with), and when I am happy with the output from diff, I conclude it with "commit -a" to conclude the whole thing. I can see that I would be irritated to if that final step failed.
But I suspect the irritation would be relatively mild: "ah, these days I shouldn't use 'commig -a' to conclude these incremental change-review-add cycle; instead, I should say 'add -u' then 'commit'".