Paolo Ciarrocchi wrote:
On 10/5/07, Andreas Ericsson <ae@xxxxxx> wrote:
Paolo Ciarrocchi wrote:
On 10/4/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
Hi,
On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:
On 10/4/07, Wincent Colaiuta <win@xxxxxxxxxxx> 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@xxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
