Re: Question about "git commit -a"

["Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com>]

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 A B E
>
>
> This isn't really a valid command. I'm not sure where you got it from.

Doh! Don't consider it, it's just a silly copy and paste error! It has
no meaning!

> > $ 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".

> > $ git C D
>
> Again not a valid command, but...

See above, just a very silly copy and paste error.

> > $ 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.

Regards
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com