Paolo Ciarrocchi wrote:
quoted text
> On 10/5/07, Andreas Ericsson <ae@op5.se> wrote:
>> Paolo Ciarrocchi wrote:
>>> On 10/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>> Hi,
>>>>
>>>> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:
>>>>
>>>>> On 10/4/07, Wincent Colaiuta <win@wincent.com> wrote:
>>>>>>> Am I wrong?
>>>>>> About it being a majority, yes, I suspect so.
>>>>>>
>>>>> Maybe in the next survey we should include question "do you usually do
>>>>> 'git commit' or 'git commit -a'" :-)
>>>> Not meaning to discourage you, but it is a known fact that Linus does "git
>>>> commit" without "-a" quite often.
>>>>
>>>> And if that were not bad enough for your plan, I myself omit "-a"
>>>> regularly.  So you would get a veto from me, too.
>>> So you are used to do something like (please correct me if I'm wrong):
>>> - modify A
>>> - modify B
>>> - modify C
>>> - modify D
>>> - modify E
>>>
> 
>>> $ git add A B E (A, B and E are now in the staging area)
>>> $ git commit -m "I just modified A,B and E"
>> I do something like that, except that for full-file commits I'd rather
>> say
>>
>>         git commit -s A B E
>>
>> I never pass -m to git commit. It's too easy to get into habit of being
>> sloppy with historic documentation that way.
> 
> Right.
> But in the scenario you described isn't enough to type "git commit -s".
> Why did you write "git commit -s A B E".
> 

Because that way I don't have to do "git add A B E" first.

quoted text
> 
>>> $ git add C D (C and D are now in the staging area)
>>> $ git commit -m "I just modified C and D"
>>>
>> See above :)
>>
>> There's also the times when I hack on some feature and find some small
>> bug/easy-to-write-feature, so I make the change for that other thing,
>> swap to a different branch and do 'git commit -s --interactive' to
>> just break out that small fix.
>>
>> Or if I have to add some logic to some other function in a file I've
>> modified for other purposes and want it to be two separate commits,
>> I just make the change and then run 'git commit --interactive' to
>> make it two separate commits.
> 
> Very interesting!
> 
>> I just don't do 'git commit -a' for the same reason I don't do
>> 'git commit -m', really. It tends to be habit-forming, and bisect
>> has saved my arse enough times for me to *want* my changes to be
>> small and isolated. Debugging a 5-line patch is so much more pleasant
>> than debugging a 30k-lines one that spans over several different files.
> 
> Yeah, I see.
> Thanks for your comments Andreas, very appreciated.
> 
> Just to clarify my goal, since I had that interesting discussion with
> an hg user I started looking for simple examples of the usage of the
> "staging area" to be added to the introduction to git documentation.
> The role of the index/staging area seems to be something complex for a
> git newbie.
> 

Yes, but it's so enormously powerful once you get a grip on it that I can't
for the life of me imagine an scm system without it. You just can't do
"scm commit --interactive" without it in a sane way, or check which merge-
conflicts you've already resolved, or compare working tree with what the
next commit *will* look like, or... The list goes on. Like I said, it's so
immensely powerful that all the things you can do when you have one is, all
by itself, reason enough to switch from any other scm to git.

As for the "git commit should default to -a" discussion, I think it's pretty
clear where I stand ;-)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html