Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)
- From
Jacob Helwig <jacob.helwig@gmail.com>
- Date
- Apr 24, 2010, 19:57 UTC
- Message-ID
- <r2j8c9a061004241257ma6ad8fa6uec9498d3fe16e409@mail.gmail.com>
- In-Reply-To
- <alpine.LFD.2.00.1004241539270.7232@xanadu.home>
On Sat, Apr 24, 2010 at 12:44, Nicolas Pitre <nico@fluxnic.net> wrote:
Show 28 quoted lines
> On Sat, 24 Apr 2010, Jacob Helwig wrote: > >> On Sat, Apr 24, 2010 at 11:54, Petr Baudis <pasky@suse.cz> wrote: >> > Are there valid user scenarios where you customize your index, then want >> > to override that using -a without thinking twice? >> > >> >> Depends on what you consider "customizing your index". I add files to >> the index all the time as I'm working on things, then commit -a at the >> end "without thinking twice". >> >> For example: >> 1) Hack on something. >> 2) git add $thing >> 3) Run full test-suite. >> 4) Fix a failing module. >> 5) git add $fixed-module-and-tests >> 6) Repeat 3-5 until there's only one module failing. >> 7) Fix last failing module. >> 8) git commit -a >> >> I doubt I'm the only one that stages things as a way of marking them >> as "done", and using git commit -a to "check-off" the last "todo" >> item. > > Sure. But do you happen to often "commit -a" more changes to an already > previously modified and staged (but not committed yet) file? >
It's not uncommon. It's not the 90% case, either.
Specifically, I'd do this if I needed to make additional changes to a file that I originally thought was "done", while working on that last failing module.