Question about "git commit -a"

Question about "git commit -a"

[Paolo Ciarrocchi]

Hi all,
I was just wondering why git commit doesn't default to "-a" (yes, it's
another question that came up during a chat with a mercurial user) and
I didn't find an answer to that.

It's not a big deal but I strongly suspect that the large majority of
the git users never user git commit without the option "-a".

Am I wrong?

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

Re: Question about "git commit -a"

[Matthieu Moy]

"Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:

> Hi all,
> I was just wondering why git commit doesn't default to "-a" (yes, it's
> another question that came up during a chat with a mercurial user) and
> I didn't find an answer to that.

http://git.or.cz/gitwiki/GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717

-- 
Matthieu

Re: Question about "git commit -a"

[Paolo Ciarrocchi]

On 10/4/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
>
> > Hi all,
> > I was just wondering why git commit doesn't default to "-a" (yes, it's
> > another question that came up during a chat with a mercurial user) and
> > I didn't find an answer to that.
>
> http://git.or.cz/gitwiki/GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717

Ooops... I'm really that bad in googling for an information ;-(

Thanks and sorry for the noise.

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

Re: Question about "git commit -a"

[Wincent Colaiuta]

El 4/10/2007, a las 17:38, Paolo Ciarrocchi escribió:

> Hi all,
> I was just wondering why git commit doesn't default to "-a" (yes, it's
> another question that came up during a chat with a mercurial user) and
> I didn't find an answer to that.
>
> It's not a big deal but I strongly suspect that the large majority of
> the git users never user git commit without the option "-a".

<http://git.or.cz/gitwiki/GitFaq>

Specifically:

<http://git.or.cz/gitwiki/ 
GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717>

> Am I wrong?

About it being a majority, yes, I suspect so.

Cheers,
Wincent

Re: Question about "git commit -a"

[Nguyen Thai Ngoc Duy]

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'" :-)

-- 
Duy

Re: Question about "git commit -a"

[Johannes Schindelin]

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.

Ciao,
Dscho

Re: Question about "git commit -a"

[Nguyen Thai Ngoc Duy]

On 10/5/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.

I obviously forgot to mention I do use git-commit without -a. I just
wanted to know which way the real majority of git users prefers.
-- 
Duy

Re: Question about "git commit -a"

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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.

Ditto.  I use `git commit` more often than `git commit -a`.

Actually scratch that, I use `git gui` more often than I use `git
commit -a` but the point holds.  I stage things long before I ever
think about what the commit message should say.  Its very rare that
I am committing without staging something first, usually its a one
liner fix for something and the -a just is the shorter way to stage
the change.

Early on in my Git days I didn't grasp how *useful* it is to stage
first.  Now I can't work without it.  At least for any change more
than 1 line.  :)

-- 
Shawn.

Re: Question about "git commit -a"

[Paolo Ciarrocchi]

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
$ 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"
$ git C D
$ git add C D (C and D are now in the staging area)
$ git commit -m "I just modified C and D"

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/

Re: Question about "git commit -a"

[Andreas Ericsson]

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.

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

> $ git C D

Again not a valid command, but...

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

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Question about "git commit -a"

[Paolo Ciarrocchi]

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

Re: Question about "git commit -a"

[Andreas Ericsson]

Paolo Ciarrocchi wrote:
> 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.

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

Re: Question about "git commit -a"

[Matthieu Moy]

Andreas Ericsson <ae@op5.se> writes:

> 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,

darcs|hg record do a very similar job. The real difference between
darcs and others here is not "scm commit --interactive", but the fact
that you can split the work among multiple commands, the index
maintains a persistant state.

> or check which merge- conflicts you've already resolved,

At least bzr and baz have this kind of conflict management. It's just
a separate file, containing the list of unresolved conflicts.

> or compare working tree with what the next commit *will* look like,

To me, *that* is the point.

-- 
Matthieu

Re: Question about "git commit -a"

[Andreas Ericsson]

Matthieu Moy wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
>> 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,
> 
> darcs|hg record do a very similar job. The real difference between
> darcs and others here is not "scm commit --interactive", but the fact
> that you can split the work among multiple commands, the index
> maintains a persistant state.
> 
>> or check which merge- conflicts you've already resolved,
> 
> At least bzr and baz have this kind of conflict management. It's just
> a separate file, containing the list of unresolved conflicts.
> 

Can you check them against any revision you want? If so, I'm impressed :)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Question about "git commit -a"

[Matthieu Moy]

Andreas Ericsson <ae@op5.se> writes:

>>> or check which merge- conflicts you've already resolved,
>>
>> At least bzr and baz have this kind of conflict management. It's just
>> a separate file, containing the list of unresolved conflicts.
>
> Can you check them against any revision you want? If so, I'm
> impressed :)

If you mean s/check/diff/, not in a simple way, no. Otherwise, I don't
understand what you mean by "check merge-conflicts you've already
resolved against any revision".

-- 
Matthieu

Re: Question about "git commit -a"

[Andreas Ericsson]

Matthieu Moy wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
>>>> or check which merge- conflicts you've already resolved,
>>> At least bzr and baz have this kind of conflict management. It's just
>>> a separate file, containing the list of unresolved conflicts.
>> Can you check them against any revision you want? If so, I'm
>> impressed :)
> 
> If you mean s/check/diff/, not in a simple way, no. Otherwise, I don't
> understand what you mean by "check merge-conflicts you've already
> resolved against any revision".
> 

Actually, I meant "diff the staged area against any random commit". It's
really nice to do after a bisect, where you know what the bad commit looks
like, and how the code changed to introduce the bug.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Question about "git commit -a"

[Paolo Ciarrocchi]

On 10/5/07, Andreas Ericsson <ae@op5.se> wrote:
[...]
> As for the "git commit should default to -a" discussion, I think it's pretty
> clear where I stand ;-)

Fair enough.

Another try to have an easy explanation of how the staging area works:

paolo@paolo-desktop:~/HowIndexWorks$ ls
A  B  C  D  E  F  G

Now I edit A,B,C,D and E:

$ echo A >> A
$ echo B >> B
$ echo C >> C
$ echo D >> D
$ echo E >> E

I now realize want to only commit the changes I did to A,B,C,D.
First step is to place A,B,C and D into the staging area:
$ git add A B C D

Now I can commit:
$ git commitpaolo@paolo-desktop:~/HowIndexWorks$ git commit
Created commit 16032dc: I modified A,B,C and D
 4 files changed, 4 insertions(+), 0 deletions(-)

It's now time to work on F and G:
$ echo F >> F
$ echo G >> G

Current status is:
paolo@paolo-desktop:~/HowIndexWorks$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   E
#       modified:   F
#       modified:   G

Instead of adding E,F and G to the staging are and then commit them in
two steps I can using a single command:
$ git commit E F G (in this case it's equivalent to git commit -a)

paolo@paolo-desktop:~/HowIndexWorks$ git commit E F G
Created commit 69ec8be: I modified E, F and G
 3 files changed, 3 insertions(+), 0 deletions(-)

status now is:
paolo@paolo-desktop:~/HowIndexWorks$ git status
# On branch master
nothing to commit (working directory clean)

Regards,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/

Re: Question about "git commit -a"

[Andreas Ericsson]

Paolo Ciarrocchi wrote:
> On 10/5/07, Andreas Ericsson <ae@op5.se> wrote:
> [...]
>> As for the "git commit should default to -a" discussion, I think it's pretty
>> clear where I stand ;-)
> 
> Fair enough.
> 
> Another try to have an easy explanation of how the staging area works:
> 
> paolo@paolo-desktop:~/HowIndexWorks$ ls
> A  B  C  D  E  F  G
> 
> Now I edit A,B,C,D and E:
> 
> $ echo A >> A
> $ echo B >> B
> $ echo C >> C
> $ echo D >> D
> $ echo E >> E
> 
> I now realize want to only commit the changes I did to A,B,C,D.
> First step is to place A,B,C and D into the staging area:
> $ git add A B C D
> 
> Now I can commit:
> $ git commitpaolo@paolo-desktop:~/HowIndexWorks$ git commit
> Created commit 16032dc: I modified A,B,C and D
>  4 files changed, 4 insertions(+), 0 deletions(-)
> 
> It's now time to work on F and G:
> $ echo F >> F
> $ echo G >> G
> 
> Current status is:
> paolo@paolo-desktop:~/HowIndexWorks$ git status
> # On branch master
> # Changed but not updated:
> #   (use "git add <file>..." to update what will be committed)
> #
> #       modified:   E
> #       modified:   F
> #       modified:   G
> 
> Instead of adding E,F and G to the staging are and then commit them in
> two steps I can using a single command:
> $ git commit E F G (in this case it's equivalent to git commit -a)
> 

He. It's like comparing a duracell battery to the sun, but yes, that's
one of the operations where the index is involved. But after doing your
git-add thing above, you could also have continued hacking on A B C D,
and git would only have committed the state where you did "git add".
When you stop to think about this, you'll realize that it's a really
powerful thing, as it lets you keep on hacking even when you don't
really know where you'll end up.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Question about "git commit -a"

[Matthieu Moy]

Andreas Ericsson <ae@op5.se> writes:

> He. It's like comparing a duracell battery to the sun, but yes, that's
> one of the operations where the index is involved. But after doing your
> git-add thing above, you could also have continued hacking on A B C D,
> and git would only have committed the state where you did "git add".
> When you stop to think about this, you'll realize that it's a really
> powerful thing, as it lets you keep on hacking even when you don't
> really know where you'll end up.

That usage is indeed very close to a micro-micro-throwable branch.

Instead of doing:

<hack>
<diff>
<commit>

<hack>
<diff>
<commit>

# Oh, gosh, I didn't want that! | # Yes, _this_ is what I want
$ git reset --hard HEAD^^       | $ git checkout HEAD^^
                                | $ git merge --squash HEAD@{1}
                                  (untested)

You'd do:

<hack>
<diff>
<add>

<hack>
<diff>
<add>

# Oh, gosh, I didn't want that! | # Yes, _this_ is what I want
$ git reset --hard              | $ git commit

The two flows are both similar and different. In the first case, you
can't come back to an arbitrary step within your development, but
since you didn't actually commit, and just ran "add", it's precisely
because you thought this state was not one you wanted to come back to
later. And at the time you commit, you don't have to tell git to
forget about the temporary branch, the succession of "git add" was
just for you, not to keep in history.


Actually, most of the time, I commit only when my index matches the
working tree (i.e. when status shows me only green, with color.status
= auto), so "commit" or "commit -a" don't change the result, but I
validate my own changes with "add", and give the whole thing a
descriptive message with "commit".

-- 
Matthieu

Re: Question about "git commit -a"

[Kristian Høgsberg]

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

I understand why people like staging and commit without -a, seeing how
it's faster and all, but I have a serious problem with this practice
that I haven't seen brought up on the list.  How do you know what you
commit actually works or even compiles?  The reason that I almost
exclusively use -a with commit is that I want to know that what I just
compiled and tested is what I will be committing.  I don't want to just
commit half the files in my working copy, I want to make sure that the
exact state of my project that I just compiled and tested is what gets
into version controlled history.

git commit -a isn't sloppy to me - eye balling some subset of your
working copy and committing that under the assumption that you don't
make mistakes and don't need to compile what you commit... that is
sloppy.

Kristian

Re: Question about "git commit -a"

[Matthieu Moy]

Kristian Høgsberg <krh@redhat.com> writes:

> I understand why people like staging and commit without -a, seeing how
> it's faster and all,

Actually, commit without -a is not much faster, since it runs "status"
internally, to show it to the user when launching the editor. So, it
still checks for changes in the working tree.

> but I have a serious problem with this practice that I haven't seen
> brought up on the list. How do you know what you commit actually
> works or even compiles?

That's a general problem with partial commits, and that's why I
personnaly don't like partial commits in general ($scm commit file1
file2 has the same problem, \forall $scm).

To me, the right approach to partial commit is to stash the unwanted
changes, test, commit, and unstash.

(side note: it would be cool to have a "git stash --unstaged" command,
to put the unstaged changes aside, and match the tree to the index. A
good approximation for that is:

$ git stash                  # put all aside
$ git reset --mixed stash^2  # get back what the index used to be
$ git add -u                 # and put it back into the index.
)

*But*, the cool thing with git is that you can view rather easily not
only what you're about to commit (git diff --cached), but also what
you're about _not_ to commit (git diff). So, if the unstaged changes
are trivial enough, it can be OK (for example, Linus changes the linux
version in a Makefile a few commits before the release, and doesn't
add it to the index, to keep it as a reminder).

But I agree with your that splitting a huge patch into smaller ones
using just the index is bad practice, except if you intend to come
back to each commit and test it later.

-- 
Matthieu

Re: Question about "git commit -a"

[Marko Macek]

> I understand why people like staging and commit without -a, seeing how
> it's faster and all, but I have a serious problem with this practice
> that I haven't seen brought up on the list.  How do you know what you
> commit actually works or even compiles?  The reason that I almost
> exclusively use -a with commit is that I want to know that what I just
> compiled and tested is what I will be committing.  I don't want to just
> commit half the files in my working copy, I want to make sure that the
> exact state of my project that I just compiled and tested is what gets
> into version controlled history.
> 
> git commit -a isn't sloppy to me - eye balling some subset of your
> working copy and committing that under the assumption that you don't
> make mistakes and don't need to compile what you commit... that is
> sloppy.

Agreed. For this reason git-commit without -a, staging, index, ... is
not really interesting to me.

In CVS and subversion (which has nicer working-copy command line interface IMHO),
I simply make a copy of the working copy, revert the non-commitable parts, build,
commit the minor changes, and then update the first copy. For larger projects,
where this can be slow, I use diff/revert/patch.

Small checkins are nice for git-bisect, but if they don't build...

Mark

Re: Question about "git commit -a"

[Andy Parkins]

On Friday 2007, October 05, Marko Macek wrote:

> In CVS and subversion (which has nicer working-copy command line
> interface IMHO), I simply make a copy of the working copy, revert the
> non-commitable parts, build, commit the minor changes, and then update
> the first copy. For larger projects, where this can be slow, I use
> diff/revert/patch.
>
> Small checkins are nice for git-bisect, but if they don't build...

Who cares?  Commits that build isn't the only reason for small commits.

git-bisect is nice and small buildable commits is something to aim for.  
However, there is more to software history that buildable commits.

I hardly ever git-bisect, and I hardly ever checkout old revisions, however 
I read the log _all the time_.  The smaller the commit and the better the 
log message the more quickly I'll understand what was going on.  In the end 
even if the commit doesn't build as long as the log message is a good 
description of what the commit does and that thing is an isolated change 
then the revision has achieved its goal for me.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: Question about "git commit -a"

[Linus Torvalds]

On Sat, 6 Oct 2007, Andy Parkins wrote:
> 
> Who cares?  Commits that build isn't the only reason for small commits.

More importantly, while it's true that you should always test all your 
changes, quite often they really *are* obviously separate.

I've mentioned this as an example lots of times, but I often tend to have 
multiple independent things in my tree at the same time. One of the 
"clearly independent" ones is the fact that I historically tended to 
update my Makefile for the next version number several days before I do 
the actual release, just to remind me (I used to forget to bump the 
version number, so..).

So I often have a dirty main makefile, but that doesn't mean that I'm 
going to commit it until I'm ready. I want to (no - *need* to) be able to 
pull and apply patches from other people despite the fact that I have some 
dirty state.

[ It's not just the makefile: almost all of what I do these days is pull 
  and apply patches, but I also send out suggestions to other developers 
  by email, and I often end up keeping my suggestion around in my tree as 
  dirty state. I could use a topic branch, but the thing is, I don't 
  actually want to save it - but not only do I actually like seeing the 
  "couldn't merge due to dirty state" because that tells me I got the fix 
  back, but I like just eatign my dogfood and compiling the kernel with 
  the suggestions I sent out ]

So it's quite ok to have multiple independent changes going on it the 
tree, and there's absolutely *zero* reason to think you should commit them 
together (quite the reverse). Maybe this isn't all that common for a 
*small* thing, but I pretty much guarantee that large projects always end 
up doing somethng like this.

And making the *default* workflow do something bad - namely commit 
everything blindly - is not a good idea. I'd rather have the normal 
workflow basically try to encourage many small commits, because while it's 
true that they may not have been tested individually, 99% of the time any 
linkages are pretty obvious.

(Side note: the *most* common failure to check stuff in completely tends 
to be one that other SCM's also have, for all the same reasons: forgetting 
to *add* a new file. I suspect the git model of "add all new changes" 
whether new files or old, actually _helps_ avoid that error, but quite 
frankly, I don't think we'll ever get away from it. It's just too easy a 
mistake to do).

			Linus

Re: Question about "git commit -a"

[Wincent Colaiuta]

El 5/10/2007, a las 20:16, Marko Macek escribió:

> In CVS and subversion (which has nicer working-copy command line  
> interface IMHO),
> I simply make a copy of the working copy, revert the non-commitable  
> parts, build,
> commit the minor changes, and then update the first copy. For  
> larger projects,
> where this can be slow, I use diff/revert/patch.

This sounds painful compared to Dmitry's method (pasted below) if you  
care about all published changes being buildable and passing all the  
tests...

El 5/10/2007, a las 23:10, Dmitry Potapov escribió:

> IMHO, the best practice is to recompile everything step-wise in
> a clean directory before you are going to publish your changes.
> It can be done automatically by script, while you do something
> useful, like reading this mailing-list :)

Cheers,
Wincent

Re: Question about "git commit -a"

[Dmitry Potapov]

On Fri, Oct 05, 2007 at 11:56:03AM -0400, Kristian Høgsberg wrote:
> I understand why people like staging and commit without -a, seeing how
> it's faster and all, but I have a serious problem with this practice
> that I haven't seen brought up on the list.  How do you know what you
> commit actually works or even compiles?

You don't. Even with 'commit -a' there is no guarantee that the
result will compile, because you can forget to add a new file.
IMHO, the best practice is to recompile everything step-wise in 
a clean directory before you are going to publish your changes.
It can be done automatically by script, while you do something
useful, like reading this mailing-list :)

Dmitry

Re: Question about "git commit -a"

[Marko Macek]

Dmitry Potapov wrote:
> You don't. Even with 'commit -a' there is no guarantee that the
> result will compile, because you can forget to add a new file.

Actually, it would be a good idea for commit to report an error if there
are any new files that have not been 'added' or 'ignored' (or even 
if there are missing files that have not been 'deleted'.

Perhaps I'll add this to my git wrapper scripts.

Even for normal git-commit it might be nice to report an error if there are any
unstaged files unless -a or -i option is specified.

Mark

Re: Question about "git commit -a"

[Dmitry Potapov]

On 10/7/07, Marko Macek <Marko.Macek@gmx.net> wrote:
> Dmitry Potapov wrote:
> > You don't. Even with 'commit -a' there is no guarantee that the
> > result will compile, because you can forget to add a new file.
>
> Actually, it would be a good idea for commit to report an error if there
> are any new files that have not been 'added' or 'ignored'

If it is good for you, you can add this check to your pre-commit hook.
However, I don't like your idea at all. Sometimes, you do want to have
some file that is not 'added' or 'ignored' as a reminder that you have
something else to do. IMHO, git acts in the most reasonable way in this
respect. When you say 'commit -a' and you have some files not added,
it will show you all untracked files in your editor when you type a
commit message. So, it is more difficult to forget to add a new file
with git than with many other version control systems.

> (or even
> if there are missing files that have not been 'deleted'.

Actually, 'commit -a' will automatically delete all missing files.
IMHO, it is the right thing to do.

Dmitry

Re: Question about "git commit -a"

[Johannes Schindelin]

Hi,

On Sun, 7 Oct 2007, Marko Macek wrote:

> Dmitry Potapov wrote:
> > You don't. Even with 'commit -a' there is no guarantee that the
> > result will compile, because you can forget to add a new file.
> 
> Actually, it would be a good idea for commit to report an error if there 
> are any new files that have not been 'added' or 'ignored' (or even if 
> there are missing files that have not been 'deleted'.

It is no error.

And it is reported.  That is the whole _point_ of having git status output 
both changed-but-not-staged and untracked files.

Of course, you only see that when you do not provide the message within 
the editor, but from the command line.  But then chances are that your 
message is too short anyway.

Ciao,
Dscho

Re: Question about "git commit -a"

[Wincent Colaiuta]

El 5/10/2007, a las 10:39, Paolo Ciarrocchi escribió:

> 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
> $ 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"
> $ git C D
> $ git add C D (C and D are now in the staging area)
> $ git commit -m "I just modified C and D"

The conceptual shift is that in Git your index and not your working  
directory is your staging area, unlike (most/all?) other SCMs. If you  
fire up gitk and look at the development history of Git itself you'll  
see that it's one of the "cleanest" out there, and as you learn Git  
you learn about the various tools and tricks that it provides that  
makes it easier for a developer community to produce such a clean  
history; the index as a staging area is one of the key factors.

The basic workflow is:

   # work on a single change
   edit A
   git add A
   edit B
   git add B

   # see unrelated thing that needs to be fixed, but don't add  
(stage) it yet
   edit C

   # commit first change, then second one
   git commit -s
   git commit -s C

This is just one example of how having a staging area that you can  
control independently of your working tree can help you. There are  
other possible workflows and you discover them through use, but they  
all share the basic idea that you use the staging area to provide you  
with better control.

Sometimes you're trying to work on a single thing and you see a  
change within a single file that isn't related. In that case you have  
an even finer level of granularity available and can use "git add -- 
interactive" to add only specific hunks.

Finally, closely related to this idea of maintaining a clean history  
is the newly-added and wonderful "git stash". If you have a  
relatively complicated work in progress already half-staged in the  
index and you see something else relatively complicated that you want  
to attend to straight away then you can easily switch to the second  
task, commit it, and go back to the first task, thus keeping your  
development history nice and clean. This is a beautiful example of  
your SCM facilitating your work and making it easy rather than  
forcing you to jump through hoops. See the git-stash man page for  
more details.

I think all of this is incredibly powerful useful stuff, and all of  
it comes at a very low cost; it's easy to learn and doesn't require  
you to do any magical and complex history rewriting in order to get a  
nice clean history.

And on the subject of staging areas, thanks to "git commit --amend"  
you can even use the last commit as a kind of secondary, addditional  
staging area, providing you haven't published that commit yet. In  
other words, I frequently do:

   git show HEAD

Immediately after committing and if I don't like what I see I make  
modifications as necessary and do:

   git commit --amend

Cheers,
Wincent

Re: Question about "git commit -a"

[Andy Parkins]

On Thursday 2007, October 04, Paolo Ciarrocchi wrote:
> Hi all,
> I was just wondering why git commit doesn't default to "-a" (yes, it's
> another question that came up during a chat with a mercurial user) and
> I didn't find an answer to that.
>
> It's not a big deal but I strongly suspect that the large majority of
> the git users never user git commit without the option "-a".
>
> Am I wrong?

Yes, I think you are.  I suspect that most users start out using git 
commit -a, because that's the workflow they were used to with their 
previous SCM.  What happened to me was I started with

 git commit -a

Then I started adding files one at a time

 git add <file>

Now I cherry pick hunks together in coherent groups 

 git add -i

Once you figure out that git lets you turn your development history from a 
simple snapshotter to telling the story of the project's development, 
you'll find you want finer and finer control over what you're committing.



Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: Question about "git commit -a"

[Miles Bader]

Andy Parkins <andyparkins@gmail.com> writes:
> Now I cherry pick hunks together in coherent groups 
>
>  git add -i

Ooooohhhhh,.....

Boy I didn't know about add -i... that looks, really, really, really
useful...

Thanks,

-miles

-- 
Run away!  Run away!

Re: Question about "git commit -a"

[David Soria]

Am Thu, 04 Oct 2007 17:38:25 +0200 schrieb Paolo Ciarrocchi:

> Hi all,
> I was just wondering why git commit doesn't default to "-a" (yes, it's
> another question that came up during a chat with a mercurial user) and
> I didn't find an answer to that.


in fact i do just a git-config alias.commit 'commit -a' in my repository

Re: Question about "git commit -a"

[Alex Riesen]

David Soria, Fri, Oct 05, 2007 00:34:11 +0200:
> Am Thu, 04 Oct 2007 17:38:25 +0200 schrieb Paolo Ciarrocchi:
> 
> > Hi all,
> > I was just wondering why git commit doesn't default to "-a" (yes, it's
> > another question that came up during a chat with a mercurial user) and
> > I didn't find an answer to that.
> 
> 
> in fact i do just a git-config alias.commit 'commit -a' in my repository
> 

Either you have a specially modified git (the alias expansion code) or
you just said not exactly truth. You can't alias the git commands (see
git.c's main).

Re: Question about "git commit -a"

[Johannes Schindelin]

Hi,

On Thu, 4 Oct 2007, David Soria wrote:

> Am Thu, 04 Oct 2007 17:38:25 +0200 schrieb Paolo Ciarrocchi:
> 
> > Hi all,
> > I was just wondering why git commit doesn't default to "-a" (yes, it's
> > another question that came up during a chat with a mercurial user) and
> > I didn't find an answer to that.
> 
> 
> in fact i do just a git-config alias.commit 'commit -a' in my repository

Which will not work, because we do not allow overriding of 
programs/builtins by aliases.

This has technical reasons and cannot be fixed.

Ciao,
Dscho