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