On Fri, Jun 17, 2016 at 6:46 AM, Damien Pollet <[email protected]> wrote:
>
> On 17 June 2016 at 00:08, Eliot Miranda <[email protected]> wrote:
>>
>> What I don't understand is how, or indeed why, one stages modified files.
>> I get that adding files requires informing git. But why doesn't "git
>> commit" commit modified files by default? Why do I have to use git commit
>> -a to include modified files?
>
>
> The mindset with git is that your working copy is a sort of experimentation
> area where you can have a crazy scientist attitude. When you commit,
> however, you switch hats and become the thorough developer that cares about
> your future self, and therefore has done all changes in a perfect didactic
> sequence so that you can understand what the hell your future-past-self was
> doing.
>
> If your crazy-scientist-self is already auto-censored into producing limpid
> incremental patches, then he can use git aliases for his preferred workflow
> (for instance I have git ci, git co, git st configured to mimic their svn
> counterparts; git staged shows a diff of what's to be committed next, etc)
While creating svn like aliases and using "commit -a" may initially
aid transition to git from svn, consider that this is a bit like a C
programmer migrating to C++ to earn OO, versus learning OO by using
Smalltalk. The hybrid nature of the C++ impedes them changing their
*mindset* to use OO the full power of OO. In some respects it is
better to make the effort up front to change mindset, but of course
that needs to balanced against productivity today.
cheers -ben
P.S. Just to complete my other reply...
> Personally I like the staging area as a final check to observe what I'm
> *really* committing,
Instead of "commit -a" which atomically does... git add -u ; git commit
I like to separately use something like...
git add -u ; git diff --staged ; git commit
cheers -ben
