{"thread":{"id":"10139","subject":"Question about \"git commit -a\"","startedAt":"2007-10-04T15:38:25Z","lastAt":"2007-10-07T16:26:54Z","messageCount":35,"participants":["Paolo Ciarrocchi","Matthieu Moy","Wincent Colaiuta","Nguyen Thai Ngoc Duy","Johannes Schindelin","Andy Parkins","Shawn O. Pearce","David Soria","Alex Riesen","Miles Bader","Andreas Ericsson","Kristian Høgsberg","Marko Macek","Dmitry Potapov","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"54834","messageId":"4d8e3fd30710040838t48bb590erbd90a8c4a1c6e932@mail.gmail.com","threadId":"10139","inReplyTo":null,"subject":"Question about \"git commit -a\"","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2007-10-04T15:38:25Z","receivedAt":"2007-10-04T15:38:25Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"Hi all,\nI was just wondering why git commit doesn't default to \"-a\" (yes, it's\nanother question that came up during a chat with a mercurial user) and\nI didn't find an answer to that.\n\nIt's not a big deal but I strongly suspect that the large majority of\nthe git users never user git commit without the option \"-a\".\n\nAm I wrong?\n\nRegards,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\nhttp://ubuntista.blogspot.com\n"},{"id":"54836","messageId":"vpqk5q2x4ud.fsf@bauges.imag.fr","threadId":"10139","inReplyTo":"4d8e3fd30710040838t48bb590erbd90a8c4a1c6e932@mail.gmail.com","subject":"Re: Question about \"git commit -a\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-10-04T15:43:54Z","receivedAt":"2007-10-04T15:43:54Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Paolo Ciarrocchi\" writes:\n\n> Hi all,\n> I was just wondering why git commit doesn't default to \"-a\" (yes, it's\n> another question that came up during a chat with a mercurial user) and\n> I didn't find an answer to that.\n\nhttp://git.or.cz/gitwiki/GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717\n\n-- \nMatthieu\n"},{"id":"54838","messageId":"4d8e3fd30710040848l594d714vbd6a62e69b71f7d9@mail.gmail.com","threadId":"10139","inReplyTo":"vpqk5q2x4ud.fsf@bauges.imag.fr","subject":"Re: Question about \"git commit -a\"","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2007-10-04T15:48:12Z","receivedAt":"2007-10-04T15:48:12Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 10/4/07, Matthieu Moy wrote:\n> \"Paolo Ciarrocchi\" writes:\n>\n> > Hi all,\n> > I was just wondering why git commit doesn't default to \"-a\" (yes, it's\n> > another question that came up during a chat with a mercurial user) and\n> > I didn't find an answer to that.\n>\n> http://git.or.cz/gitwiki/GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717\n\nOoops... I'm really that bad in googling for an information ;-(\n\nThanks and sorry for the noise.\n\nRegads,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\nhttp://ubuntista.blogspot.com\n"},{"id":"54844","messageId":"545CB3B2-96B3-4853-9397-B42F4F268A15@wincent.com","threadId":"10139","inReplyTo":"4d8e3fd30710040838t48bb590erbd90a8c4a1c6e932@mail.gmail.com","subject":"Re: Question about \"git commit -a\"","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-04T15:58:47Z","receivedAt":"2007-10-04T15:58:47Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 4/10/2007, a las 17:38, Paolo Ciarrocchi escribió:\n\n> Hi all,\n> I was just wondering why git commit doesn't default to \"-a\" (yes, it's\n> another question that came up during a chat with a mercurial user) and\n> I didn't find an answer to that.\n>\n> It's not a big deal but I strongly suspect that the large majority of\n> the git users never user git commit without the option \"-a\".\n\n\n\nSpecifically:\n\n\n\n> Am I wrong?\n\nAbout it being a majority, yes, I suspect so.\n\nCheers,\nWincent\n"},{"id":"54869","messageId":"fcaeb9bf0710041333l636b2c1fn4d8f3298000127c7@mail.gmail.com","threadId":"10139","inReplyTo":"545CB3B2-96B3-4853-9397-B42F4F268A15@wincent.com","subject":"Re: Question about \"git commit -a\"","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-10-04T20:33:52Z","receivedAt":"2007-10-04T20:33:52Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 10/4/07, Wincent Colaiuta wrote:\n> > Am I wrong?\n>\n> About it being a majority, yes, I suspect so.\n>\n\nMaybe in the next survey we should include question \"do you usually do\n'git commit' or 'git commit -a'\" :-)\n\n-- \nDuy\n"},{"id":"54875","messageId":"Pine.LNX.4.64.0710042209410.4174@racer.site","threadId":"10139","inReplyTo":"fcaeb9bf0710041333l636b2c1fn4d8f3298000127c7@mail.gmail.com","subject":"Re: Question about \"git commit -a\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-04T21:10:50Z","receivedAt":"2007-10-04T21:10:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:\n\n> On 10/4/07, Wincent Colaiuta wrote:\n> > > Am I wrong?\n> >\n> > About it being a majority, yes, I suspect so.\n> >\n> \n> Maybe in the next survey we should include question \"do you usually do \n> 'git commit' or 'git commit -a'\" :-)\n\nNot meaning to discourage you, but it is a known fact that Linus does \"git \ncommit\" without \"-a\" quite often.\n\nAnd if that were not bad enough for your plan, I myself omit \"-a\" \nregularly. So you would get a veto from me, too.\n\nCiao,\nDscho\n"},{"id":"54877","messageId":"fcaeb9bf0710041416n60c94922k99501d3f1e432b79@mail.gmail.com","threadId":"10139","inReplyTo":"Pine.LNX.4.64.0710042209410.4174@racer.site","subject":"Re: Question about \"git commit -a\"","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-10-04T21:16:20Z","receivedAt":"2007-10-04T21:16:20Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 10/5/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:\n>\n> > On 10/4/07, Wincent Colaiuta wrote:\n> > > > Am I wrong?\n> > >\n> > > About it being a majority, yes, I suspect so.\n> > >\n> >\n> > Maybe in the next survey we should include question \"do you usually do\n> > 'git commit' or 'git commit -a'\" :-)\n>\n> Not meaning to discourage you, but it is a known fact that Linus does \"git\n> commit\" without \"-a\" quite often.\n>\n> And if that were not bad enough for your plan, I myself omit \"-a\"\n> regularly. So you would get a veto from me, too.\n\nI obviously forgot to mention I do use git-commit without -a. I just\nwanted to know which way the real majority of git users prefers.\n-- \nDuy\n"},{"id":"54879","messageId":"200710042225.13670.andyparkins@gmail.com","threadId":"10139","inReplyTo":"4d8e3fd30710040838t48bb590erbd90a8c4a1c6e932@mail.gmail.com","subject":"Re: Question about \"git commit -a\"","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-10-04T21:25:12Z","receivedAt":"2007-10-04T21:25:12Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007, October 04, Paolo Ciarrocchi wrote:\n> Hi all,\n> I was just wondering why git commit doesn't default to \"-a\" (yes, it's\n> another question that came up during a chat with a mercurial user) and\n> I didn't find an answer to that.\n>\n> It's not a big deal but I strongly suspect that the large majority of\n> the git users never user git commit without the option \"-a\".\n>\n> Am I wrong?\n\nYes, I think you are. I suspect that most users start out using git \ncommit -a, because that's the workflow they were used to with their \nprevious SCM. What happened to me was I started with\n\n git commit -a\n\nThen I started adding files one at a time\n\n git add \n\nNow I cherry pick hunks together in coherent groups \n\n git add -i\n\nOnce you figure out that git lets you turn your development history from a \nsimple snapshotter to telling the story of the project's development, \nyou'll find you want finer and finer control over what you're committing.\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"54880","messageId":"20071004212654.GL2137@spearce.org","threadId":"10139","inReplyTo":"Pine.LNX.4.64.0710042209410.4174@racer.site","subject":"Re: Question about \"git commit -a\"","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-04T21:26:54Z","receivedAt":"2007-10-04T21:26:54Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:\n> \n> > On 10/4/07, Wincent Colaiuta wrote:\n> > > > Am I wrong?\n> > >\n> > > About it being a majority, yes, I suspect so.\n> > >\n> > \n> > Maybe in the next survey we should include question \"do you usually do \n> > 'git commit' or 'git commit -a'\" :-)\n> \n> Not meaning to discourage you, but it is a known fact that Linus does \"git \n> commit\" without \"-a\" quite often.\n> \n> And if that were not bad enough for your plan, I myself omit \"-a\" \n> regularly. So you would get a veto from me, too.\n\nDitto. I use `git commit` more often than `git commit -a`.\n\nActually scratch that, I use `git gui` more often than I use `git\ncommit -a` but the point holds. I stage things long before I ever\nthink about what the commit message should say. Its very rare that\nI am committing without staging something first, usually its a one\nliner fix for something and the -a just is the shorter way to stage\nthe change.\n\nEarly on in my Git days I didn't grasp how *useful* it is to stage\nfirst. Now I can't work without it. At least for any change more\nthan 1 line. :)\n\n-- \nShawn.\n"},{"id":"54884","messageId":"fe3pp3$8p1$1@sea.gmane.org","threadId":"10139","inReplyTo":"4d8e3fd30710040838t48bb590erbd90a8c4a1c6e932@mail.gmail.com","subject":"Re: Question about \"git commit -a\"","fromName":"David Soria","fromEmail":"sn_@gmx.net","sentAt":"2007-10-04T22:34:11Z","receivedAt":"2007-10-04T22:34:11Z","isPatch":false,"sender":{"key":"sn_@gmx.net","avatar":"https://gravatar.com/avatar/b1075ecdd33ea094cbc23798fe8b95c73ec1ccf7bb213ac8260c719e2dd97b55?d=mp&s=160"},"body":"Am Thu, 04 Oct 2007 17:38:25 +0200 schrieb Paolo Ciarrocchi:\n\n> Hi all,\n> I was just wondering why git commit doesn't default to \"-a\" (yes, it's\n> another question that came up during a chat with a mercurial user) and\n> I didn't find an answer to that.\n\n\nin fact i do just a git-config alias.commit 'commit -a' in my repository\n"},{"id":"54888","messageId":"20071004230326.GA3092@steel.home","threadId":"10139","inReplyTo":"fe3pp3$8p1$1@sea.gmane.org","subject":"Re: Question about \"git commit -a\"","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-04T23:03:26Z","receivedAt":"2007-10-04T23:03:26Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"David Soria, Fri, Oct 05, 2007 00:34:11 +0200:\n> Am Thu, 04 Oct 2007 17:38:25 +0200 schrieb Paolo Ciarrocchi:\n> \n> > Hi all,\n> > I was just wondering why git commit doesn't default to \"-a\" (yes, it's\n> > another question that came up during a chat with a mercurial user) and\n> > I didn't find an answer to that.\n> \n> \n> in fact i do just a git-config alias.commit 'commit -a' in my repository\n> \n\nEither you have a specially modified git (the alias expansion code) or\nyou just said not exactly truth. You can't alias the git commands (see\ngit.c's main).\n"},{"id":"54889","messageId":"Pine.LNX.4.64.0710050019040.4174@racer.site","threadId":"10139","inReplyTo":"fe3pp3$8p1$1@sea.gmane.org","subject":"Re: Question about \"git commit -a\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-04T23:19:38Z","receivedAt":"2007-10-04T23:19:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 4 Oct 2007, David Soria wrote:\n\n> Am Thu, 04 Oct 2007 17:38:25 +0200 schrieb Paolo Ciarrocchi:\n> \n> > Hi all,\n> > I was just wondering why git commit doesn't default to \"-a\" (yes, it's\n> > another question that came up during a chat with a mercurial user) and\n> > I didn't find an answer to that.\n> \n> \n> in fact i do just a git-config alias.commit 'commit -a' in my repository\n\nWhich will not work, because we do not allow overriding of \nprograms/builtins by aliases.\n\nThis has technical reasons and cannot be fixed.\n\nCiao,\nDscho\n"},{"id":"54906","messageId":"buo8x6i14ie.fsf@dhapc248.dev.necel.com","threadId":"10139","inReplyTo":"200710042225.13670.andyparkins@gmail.com","subject":"Re: Question about \"git commit -a\"","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2007-10-05T06:04:25Z","receivedAt":"2007-10-05T06:04:25Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Andy Parkins writes:\n> Now I cherry pick hunks together in coherent groups \n>\n> git add -i\n\nOoooohhhhh,.....\n\nBoy I didn't know about add -i... that looks, really, really, really\nuseful...\n\nThanks,\n\n-miles\n\n-- \nRun away! Run away!\n"},{"id":"54921","messageId":"4d8e3fd30710050139j45a5a924t5c048994e3457c5f@mail.gmail.com","threadId":"10139","inReplyTo":"Pine.LNX.4.64.0710042209410.4174@racer.site","subject":"Re: Question about \"git commit -a\"","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2007-10-05T08:39:45Z","receivedAt":"2007-10-05T08:39:45Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 10/4/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:\n>\n> > On 10/4/07, Wincent Colaiuta wrote:\n> > > > Am I wrong?\n> > >\n> > > About it being a majority, yes, I suspect so.\n> > >\n> >\n> > Maybe in the next survey we should include question \"do you usually do\n> > 'git commit' or 'git commit -a'\" :-)\n>\n> Not meaning to discourage you, but it is a known fact that Linus does \"git\n> commit\" without \"-a\" quite often.\n>\n> And if that were not bad enough for your plan, I myself omit \"-a\"\n> regularly. So you would get a veto from me, too.\n\nSo you are used to do something like (please correct me if I'm wrong):\n- modify A\n- modify B\n- modify C\n- modify D\n- modify E\n\n$ git A B E\n$ git add A B E (A, B and E are now in the staging area)\n$ git commit -m \"I just modified A,B and E\"\n$ git C D\n$ git add C D (C and D are now in the staging area)\n$ git commit -m \"I just modified C and D\"\n\nCiao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"54923","messageId":"4705FB52.3030208@op5.se","threadId":"10139","inReplyTo":"4d8e3fd30710050139j45a5a924t5c048994e3457c5f@mail.gmail.com","subject":"Re: Question about \"git commit -a\"","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-05T08:52:34Z","receivedAt":"2007-10-05T08:52:34Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Paolo Ciarrocchi wrote:\n> On 10/4/07, Johannes Schindelin wrote:\n>> Hi,\n>>\n>> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:\n>>\n>>> On 10/4/07, Wincent Colaiuta wrote:\n>>>>> Am I wrong?\n>>>> About it being a majority, yes, I suspect so.\n>>>>\n>>> Maybe in the next survey we should include question \"do you usually do\n>>> 'git commit' or 'git commit -a'\" :-)\n>> Not meaning to discourage you, but it is a known fact that Linus does \"git\n>> commit\" without \"-a\" quite often.\n>>\n>> And if that were not bad enough for your plan, I myself omit \"-a\"\n>> regularly. So you would get a veto from me, too.\n> \n> So you are used to do something like (please correct me if I'm wrong):\n> - modify A\n> - modify B\n> - modify C\n> - modify D\n> - modify E\n> \n> $ git A B E\n\n\nThis isn't really a valid command. I'm not sure where you got it from.\n\n> $ git add A B E (A, B and E are now in the staging area)\n> $ git commit -m \"I just modified A,B and E\"\n\nI do something like that, except that for full-file commits I'd rather\nsay\n\n\tgit commit -s A B E\n\nI never pass -m to git commit. It's too easy to get into habit of being\nsloppy with historic documentation that way.\n\n> $ git C D\n\nAgain not a valid command, but...\n\n> $ git add C D (C and D are now in the staging area)\n> $ git commit -m \"I just modified C and D\"\n> \n\nSee above :)\n\nThere's also the times when I hack on some feature and find some small\nbug/easy-to-write-feature, so I make the change for that other thing,\nswap to a different branch and do 'git commit -s --interactive' to\njust break out that small fix.\n\nOr if I have to add some logic to some other function in a file I've\nmodified for other purposes and want it to be two separate commits,\nI just make the change and then run 'git commit --interactive' to\nmake it two separate commits.\n\nI just don't do 'git commit -a' for the same reason I don't do\n'git commit -m', really. It tends to be habit-forming, and bisect\nhas saved my arse enough times for me to *want* my changes to be\nsmall and isolated. Debugging a 5-line patch is so much more pleasant\nthan debugging a 30k-lines one that spans over several different files.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"54926","messageId":"4d8e3fd30710050206h7a177472x7c92f91204b15aa4@mail.gmail.com","threadId":"10139","inReplyTo":"4705FB52.3030208@op5.se","subject":"Re: Question about \"git commit -a\"","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2007-10-05T09:06:14Z","receivedAt":"2007-10-05T09:06:14Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 10/5/07, Andreas Ericsson wrote:\n> Paolo Ciarrocchi wrote:\n> > On 10/4/07, Johannes Schindelin wrote:\n> >> Hi,\n> >>\n> >> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:\n> >>\n> >>> On 10/4/07, Wincent Colaiuta wrote:\n> >>>>> Am I wrong?\n> >>>> About it being a majority, yes, I suspect so.\n> >>>>\n> >>> Maybe in the next survey we should include question \"do you usually do\n> >>> 'git commit' or 'git commit -a'\" :-)\n> >> Not meaning to discourage you, but it is a known fact that Linus does \"git\n> >> commit\" without \"-a\" quite often.\n> >>\n> >> And if that were not bad enough for your plan, I myself omit \"-a\"\n> >> regularly. So you would get a veto from me, too.\n> >\n> > So you are used to do something like (please correct me if I'm wrong):\n> > - modify A\n> > - modify B\n> > - modify C\n> > - modify D\n> > - modify E\n> >\n> > $ git A B E\n>\n>\n> This isn't really a valid command. I'm not sure where you got it from.\n\nDoh! Don't consider it, it's just a silly copy and paste error! It has\nno meaning!\n\n> > $ git add A B E (A, B and E are now in the staging area)\n> > $ git commit -m \"I just modified A,B and E\"\n>\n> I do something like that, except that for full-file commits I'd rather\n> say\n>\n> git commit -s A B E\n>\n> I never pass -m to git commit. It's too easy to get into habit of being\n> sloppy with historic documentation that way.\n\nRight.\nBut in the scenario you described isn't enough to type \"git commit -s\".\nWhy did you write \"git commit -s A B E\".\n\n> > $ git C D\n>\n> Again not a valid command, but...\n\nSee above, just a very silly copy and paste error.\n\n> > $ git add C D (C and D are now in the staging area)\n> > $ git commit -m \"I just modified C and D\"\n> >\n>\n> See above :)\n>\n> There's also the times when I hack on some feature and find some small\n> bug/easy-to-write-feature, so I make the change for that other thing,\n> swap to a different branch and do 'git commit -s --interactive' to\n> just break out that small fix.\n>\n> Or if I have to add some logic to some other function in a file I've\n> modified for other purposes and want it to be two separate commits,\n> I just make the change and then run 'git commit --interactive' to\n> make it two separate commits.\n\nVery interesting!\n\n> I just don't do 'git commit -a' for the same reason I don't do\n> 'git commit -m', really. It tends to be habit-forming, and bisect\n> has saved my arse enough times for me to *want* my changes to be\n> small and isolated. Debugging a 5-line patch is so much more pleasant\n> than debugging a 30k-lines one that spans over several different files.\n\nYeah, I see.\nThanks for your comments Andreas, very appreciated.\n\nJust to clarify my goal, since I had that interesting discussion with\nan hg user I started looking for simple examples of the usage of the\n\"staging area\" to be added to the introduction to git documentation.\nThe role of the index/staging area seems to be something complex for a\ngit newbie.\n\nRegards\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\nhttp://ubuntista.blogspot.com\n"},{"id":"54930","messageId":"47060BB3.3030208@op5.se","threadId":"10139","inReplyTo":"4d8e3fd30710050206h7a177472x7c92f91204b15aa4@mail.gmail.com","subject":"Re: Question about \"git commit -a\"","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-05T10:02:27Z","receivedAt":"2007-10-05T10:02:27Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Paolo Ciarrocchi wrote:\n> On 10/5/07, Andreas Ericsson wrote:\n>> Paolo Ciarrocchi wrote:\n>>> On 10/4/07, Johannes Schindelin wrote:\n>>>> Hi,\n>>>>\n>>>> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:\n>>>>\n>>>>> On 10/4/07, Wincent Colaiuta wrote:\n>>>>>>> Am I wrong?\n>>>>>> About it being a majority, yes, I suspect so.\n>>>>>>\n>>>>> Maybe in the next survey we should include question \"do you usually do\n>>>>> 'git commit' or 'git commit -a'\" :-)\n>>>> Not meaning to discourage you, but it is a known fact that Linus does \"git\n>>>> commit\" without \"-a\" quite often.\n>>>>\n>>>> And if that were not bad enough for your plan, I myself omit \"-a\"\n>>>> regularly. So you would get a veto from me, too.\n>>> So you are used to do something like (please correct me if I'm wrong):\n>>> - modify A\n>>> - modify B\n>>> - modify C\n>>> - modify D\n>>> - modify E\n>>>\n> \n>>> $ git add A B E (A, B and E are now in the staging area)\n>>> $ git commit -m \"I just modified A,B and E\"\n>> I do something like that, except that for full-file commits I'd rather\n>> say\n>>\n>> git commit -s A B E\n>>\n>> I never pass -m to git commit. It's too easy to get into habit of being\n>> sloppy with historic documentation that way.\n> \n> Right.\n> But in the scenario you described isn't enough to type \"git commit -s\".\n> Why did you write \"git commit -s A B E\".\n> \n\nBecause that way I don't have to do \"git add A B E\" first.\n\n> \n>>> $ git add C D (C and D are now in the staging area)\n>>> $ git commit -m \"I just modified C and D\"\n>>>\n>> See above :)\n>>\n>> There's also the times when I hack on some feature and find some small\n>> bug/easy-to-write-feature, so I make the change for that other thing,\n>> swap to a different branch and do 'git commit -s --interactive' to\n>> just break out that small fix.\n>>\n>> Or if I have to add some logic to some other function in a file I've\n>> modified for other purposes and want it to be two separate commits,\n>> I just make the change and then run 'git commit --interactive' to\n>> make it two separate commits.\n> \n> Very interesting!\n> \n>> I just don't do 'git commit -a' for the same reason I don't do\n>> 'git commit -m', really. It tends to be habit-forming, and bisect\n>> has saved my arse enough times for me to *want* my changes to be\n>> small and isolated. Debugging a 5-line patch is so much more pleasant\n>> than debugging a 30k-lines one that spans over several different files.\n> \n> Yeah, I see.\n> Thanks for your comments Andreas, very appreciated.\n> \n> Just to clarify my goal, since I had that interesting discussion with\n> an hg user I started looking for simple examples of the usage of the\n> \"staging area\" to be added to the introduction to git documentation.\n> The role of the index/staging area seems to be something complex for a\n> git newbie.\n> \n\nYes, but it's so enormously powerful once you get a grip on it that I can't\nfor the life of me imagine an scm system without it. You just can't do\n\"scm commit --interactive\" without it in a sane way, or check which merge-\nconflicts you've already resolved, or compare working tree with what the\nnext commit *will* look like, or... The list goes on. Like I said, it's so\nimmensely powerful that all the things you can do when you have one is, all\nby itself, reason enough to switch from any other scm to git.\n\nAs for the \"git commit should default to -a\" discussion, I think it's pretty\nclear where I stand ;-)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"54932","messageId":"vpqy7ehj2g8.fsf@bauges.imag.fr","threadId":"10139","inReplyTo":"47060BB3.3030208@op5.se","subject":"Re: Question about \"git commit -a\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-10-05T10:11:35Z","receivedAt":"2007-10-05T10:11:35Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Andreas Ericsson writes:\n\n> Yes, but it's so enormously powerful once you get a grip on it that I can't\n> for the life of me imagine an scm system without it. You just can't do\n> \"scm commit --interactive\" without it in a sane way,\n\ndarcs|hg record do a very similar job. The real difference between\ndarcs and others here is not \"scm commit --interactive\", but the fact\nthat you can split the work among multiple commands, the index\nmaintains a persistant state.\n\n> or check which merge- conflicts you've already resolved,\n\nAt least bzr and baz have this kind of conflict management. It's just\na separate file, containing the list of unresolved conflicts.\n\n> or compare working tree with what the next commit *will* look like,\n\nTo me, *that* is the point.\n\n-- \nMatthieu\n"},{"id":"54934","messageId":"47060E98.2090601@op5.se","threadId":"10139","inReplyTo":"vpqy7ehj2g8.fsf@bauges.imag.fr","subject":"Re: Question about \"git commit -a\"","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-05T10:14:48Z","receivedAt":"2007-10-05T10:14:48Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthieu Moy wrote:\n> Andreas Ericsson writes:\n> \n>> Yes, but it's so enormously powerful once you get a grip on it that I can't\n>> for the life of me imagine an scm system without it. You just can't do\n>> \"scm commit --interactive\" without it in a sane way,\n> \n> darcs|hg record do a very similar job. The real difference between\n> darcs and others here is not \"scm commit --interactive\", but the fact\n> that you can split the work among multiple commands, the index\n> maintains a persistant state.\n> \n>> or check which merge- conflicts you've already resolved,\n> \n> At least bzr and baz have this kind of conflict management. It's just\n> a separate file, containing the list of unresolved conflicts.\n> \n\nCan you check them against any revision you want? If so, I'm impressed :)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"54937","messageId":"227149BF-1220-43F2-8B0B-B7E9FCA002B1@wincent.com","threadId":"10139","inReplyTo":"4d8e3fd30710050139j45a5a924t5c048994e3457c5f@mail.gmail.com","subject":"Re: Question about \"git commit -a\"","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-05T10:48:11Z","receivedAt":"2007-10-05T10:48:11Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 5/10/2007, a las 10:39, Paolo Ciarrocchi escribió:\n\n> So you are used to do something like (please correct me if I'm wrong):\n> - modify A\n> - modify B\n> - modify C\n> - modify D\n> - modify E\n>\n> $ git A B E\n> $ git add A B E (A, B and E are now in the staging area)\n> $ git commit -m \"I just modified A,B and E\"\n> $ git C D\n> $ git add C D (C and D are now in the staging area)\n> $ git commit -m \"I just modified C and D\"\n\nThe conceptual shift is that in Git your index and not your working \ndirectory is your staging area, unlike (most/all?) other SCMs. If you \nfire up gitk and look at the development history of Git itself you'll \nsee that it's one of the \"cleanest\" out there, and as you learn Git \nyou learn about the various tools and tricks that it provides that \nmakes it easier for a developer community to produce such a clean \nhistory; the index as a staging area is one of the key factors.\n\nThe basic workflow is:\n\n # work on a single change\n edit A\n git add A\n edit B\n git add B\n\n # see unrelated thing that needs to be fixed, but don't add \n(stage) it yet\n edit C\n\n # commit first change, then second one\n git commit -s\n git commit -s C\n\nThis is just one example of how having a staging area that you can \ncontrol independently of your working tree can help you. There are \nother possible workflows and you discover them through use, but they \nall share the basic idea that you use the staging area to provide you \nwith better control.\n\nSometimes you're trying to work on a single thing and you see a \nchange within a single file that isn't related. In that case you have \nan even finer level of granularity available and can use \"git add -- \ninteractive\" to add only specific hunks.\n\nFinally, closely related to this idea of maintaining a clean history \nis the newly-added and wonderful \"git stash\". If you have a \nrelatively complicated work in progress already half-staged in the \nindex and you see something else relatively complicated that you want \nto attend to straight away then you can easily switch to the second \ntask, commit it, and go back to the first task, thus keeping your \ndevelopment history nice and clean. This is a beautiful example of \nyour SCM facilitating your work and making it easy rather than \nforcing you to jump through hoops. See the git-stash man page for \nmore details.\n\nI think all of this is incredibly powerful useful stuff, and all of \nit comes at a very low cost; it's easy to learn and doesn't require \nyou to do any magical and complex history rewriting in order to get a \nnice clean history.\n\nAnd on the subject of staging areas, thanks to \"git commit --amend\" \nyou can even use the last commit as a kind of secondary, addditional \nstaging area, providing you haven't published that commit yet. In \nother words, I frequently do:\n\n git show HEAD\n\nImmediately after committing and if I don't like what I see I make \nmodifications as necessary and do:\n\n git commit --amend\n\nCheers,\nWincent\n"},{"id":"54939","messageId":"vpqsl4piykb.fsf@bauges.imag.fr","threadId":"10139","inReplyTo":"47060E98.2090601@op5.se","subject":"Re: Question about \"git commit -a\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-10-05T11:35:32Z","receivedAt":"2007-10-05T11:35:32Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Andreas Ericsson writes:\n\n>>> or check which merge- conflicts you've already resolved,\n>>\n>> At least bzr and baz have this kind of conflict management. It's just\n>> a separate file, containing the list of unresolved conflicts.\n>\n> Can you check them against any revision you want? If so, I'm\n> impressed :)\n\nIf you mean s/check/diff/, not in a simple way, no. Otherwise, I don't\nunderstand what you mean by \"check merge-conflicts you've already\nresolved against any revision\".\n\n-- \nMatthieu\n"},{"id":"54942","messageId":"47062B4C.5090503@op5.se","threadId":"10139","inReplyTo":"vpqsl4piykb.fsf@bauges.imag.fr","subject":"Re: Question about \"git commit -a\"","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-05T12:17:16Z","receivedAt":"2007-10-05T12:17:16Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthieu Moy wrote:\n> Andreas Ericsson writes:\n> \n>>>> or check which merge- conflicts you've already resolved,\n>>> At least bzr and baz have this kind of conflict management. It's just\n>>> a separate file, containing the list of unresolved conflicts.\n>> Can you check them against any revision you want? If so, I'm\n>> impressed :)\n> \n> If you mean s/check/diff/, not in a simple way, no. Otherwise, I don't\n> understand what you mean by \"check merge-conflicts you've already\n> resolved against any revision\".\n> \n\nActually, I meant \"diff the staged area against any random commit\". It's\nreally nice to do after a bisect, where you know what the bad commit looks\nlike, and how the code changed to introduce the bug.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"54943","messageId":"4d8e3fd30710050519k7a3db02dk5ba9750fd8e9705f@mail.gmail.com","threadId":"10139","inReplyTo":"47060BB3.3030208@op5.se","subject":"Re: Question about \"git commit -a\"","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2007-10-05T12:19:02Z","receivedAt":"2007-10-05T12:19:02Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 10/5/07, Andreas Ericsson wrote:\n[...]\n> As for the \"git commit should default to -a\" discussion, I think it's pretty\n> clear where I stand ;-)\n\nFair enough.\n\nAnother try to have an easy explanation of how the staging area works:\n\npaolo@paolo-desktop:~/HowIndexWorks$ ls\nA B C D E F G\n\nNow I edit A,B,C,D and E:\n\n$ echo A >> A\n$ echo B >> B\n$ echo C >> C\n$ echo D >> D\n$ echo E >> E\n\nI now realize want to only commit the changes I did to A,B,C,D.\nFirst step is to place A,B,C and D into the staging area:\n$ git add A B C D\n\nNow I can commit:\n$ git commitpaolo@paolo-desktop:~/HowIndexWorks$ git commit\nCreated commit 16032dc: I modified A,B,C and D\n 4 files changed, 4 insertions(+), 0 deletions(-)\n\nIt's now time to work on F and G:\n$ echo F >> F\n$ echo G >> G\n\nCurrent status is:\npaolo@paolo-desktop:~/HowIndexWorks$ git status\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n#\n# modified: E\n# modified: F\n# modified: G\n\nInstead of adding E,F and G to the staging are and then commit them in\ntwo steps I can using a single command:\n$ git commit E F G (in this case it's equivalent to git commit -a)\n\npaolo@paolo-desktop:~/HowIndexWorks$ git commit E F G\nCreated commit 69ec8be: I modified E, F and G\n 3 files changed, 3 insertions(+), 0 deletions(-)\n\nstatus now is:\npaolo@paolo-desktop:~/HowIndexWorks$ git status\n# On branch master\nnothing to commit (working directory clean)\n\nRegards,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"54944","messageId":"47062CD7.70400@op5.se","threadId":"10139","inReplyTo":"4d8e3fd30710050519k7a3db02dk5ba9750fd8e9705f@mail.gmail.com","subject":"Re: Question about \"git commit -a\"","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-05T12:23:51Z","receivedAt":"2007-10-05T12:23:51Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Paolo Ciarrocchi wrote:\n> On 10/5/07, Andreas Ericsson wrote:\n> [...]\n>> As for the \"git commit should default to -a\" discussion, I think it's pretty\n>> clear where I stand ;-)\n> \n> Fair enough.\n> \n> Another try to have an easy explanation of how the staging area works:\n> \n> paolo@paolo-desktop:~/HowIndexWorks$ ls\n> A B C D E F G\n> \n> Now I edit A,B,C,D and E:\n> \n> $ echo A >> A\n> $ echo B >> B\n> $ echo C >> C\n> $ echo D >> D\n> $ echo E >> E\n> \n> I now realize want to only commit the changes I did to A,B,C,D.\n> First step is to place A,B,C and D into the staging area:\n> $ git add A B C D\n> \n> Now I can commit:\n> $ git commitpaolo@paolo-desktop:~/HowIndexWorks$ git commit\n> Created commit 16032dc: I modified A,B,C and D\n> 4 files changed, 4 insertions(+), 0 deletions(-)\n> \n> It's now time to work on F and G:\n> $ echo F >> F\n> $ echo G >> G\n> \n> Current status is:\n> paolo@paolo-desktop:~/HowIndexWorks$ git status\n> # On branch master\n> # Changed but not updated:\n> # (use \"git add ...\" to update what will be committed)\n> #\n> # modified: E\n> # modified: F\n> # modified: G\n> \n> Instead of adding E,F and G to the staging are and then commit them in\n> two steps I can using a single command:\n> $ git commit E F G (in this case it's equivalent to git commit -a)\n> \n\nHe. It's like comparing a duracell battery to the sun, but yes, that's\none of the operations where the index is involved. But after doing your\ngit-add thing above, you could also have continued hacking on A B C D,\nand git would only have committed the state where you did \"git add\".\nWhen you stop to think about this, you'll realize that it's a really\npowerful thing, as it lets you keep on hacking even when you don't\nreally know where you'll end up.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"54946","messageId":"vpq641livbf.fsf@bauges.imag.fr","threadId":"10139","inReplyTo":"47062CD7.70400@op5.se","subject":"Re: Question about \"git commit -a\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-10-05T12:45:40Z","receivedAt":"2007-10-05T12:45:40Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Andreas Ericsson writes:\n\n> He. It's like comparing a duracell battery to the sun, but yes, that's\n> one of the operations where the index is involved. But after doing your\n> git-add thing above, you could also have continued hacking on A B C D,\n> and git would only have committed the state where you did \"git add\".\n> When you stop to think about this, you'll realize that it's a really\n> powerful thing, as it lets you keep on hacking even when you don't\n> really know where you'll end up.\n\nThat usage is indeed very close to a micro-micro-throwable branch.\n\nInstead of doing:\n\n\n\n\n\n\n\n\n\n# Oh, gosh, I didn't want that! | # Yes, _this_ is what I want\n$ git reset --hard HEAD^^ | $ git checkout HEAD^^\n | $ git merge --squash HEAD@{1}\n (untested)\n\nYou'd do:\n\n\n\n\n\n\n\n\n\n# Oh, gosh, I didn't want that! | # Yes, _this_ is what I want\n$ git reset --hard | $ git commit\n\nThe two flows are both similar and different. In the first case, you\ncan't come back to an arbitrary step within your development, but\nsince you didn't actually commit, and just ran \"add\", it's precisely\nbecause you thought this state was not one you wanted to come back to\nlater. And at the time you commit, you don't have to tell git to\nforget about the temporary branch, the succession of \"git add\" was\njust for you, not to keep in history.\n\n\nActually, most of the time, I commit only when my index matches the\nworking tree (i.e. when status shows me only green, with color.status\n= auto), so \"commit\" or \"commit -a\" don't change the result, but I\nvalidate my own changes with \"add\", and give the whole thing a\ndescriptive message with \"commit\".\n\n-- \nMatthieu\n"},{"id":"54967","messageId":"1191599763.7117.18.camel@hinata.boston.redhat.com","threadId":"10139","inReplyTo":"4705FB52.3030208@op5.se","subject":"Re: Question about \"git commit -a\"","fromName":"Kristian Høgsberg","fromEmail":"krh@redhat.com","sentAt":"2007-10-05T15:56:03Z","receivedAt":"2007-10-05T15:56:03Z","isPatch":false,"sender":{"key":"krh@redhat.com","avatar":"https://gravatar.com/avatar/763dee6f9594ac474f725b137a39565792928e583ddf59b32befc2907409027e?d=mp&s=160"},"body":"> I just don't do 'git commit -a' for the same reason I don't do\n> 'git commit -m', really. It tends to be habit-forming, and bisect\n> has saved my arse enough times for me to *want* my changes to be\n> small and isolated. Debugging a 5-line patch is so much more pleasant\n> than debugging a 30k-lines one that spans over several different files.\n\nI understand why people like staging and commit without -a, seeing how\nit's faster and all, but I have a serious problem with this practice\nthat I haven't seen brought up on the list. How do you know what you\ncommit actually works or even compiles? The reason that I almost\nexclusively use -a with commit is that I want to know that what I just\ncompiled and tested is what I will be committing. I don't want to just\ncommit half the files in my working copy, I want to make sure that the\nexact state of my project that I just compiled and tested is what gets\ninto version controlled history.\n\ngit commit -a isn't sloppy to me - eye balling some subset of your\nworking copy and committing that under the assumption that you don't\nmake mistakes and don't need to compile what you commit... that is\nsloppy.\n\nKristian\n"},{"id":"54976","messageId":"vpq641led25.fsf@bauges.imag.fr","threadId":"10139","inReplyTo":"1191599763.7117.18.camel@hinata.boston.redhat.com","subject":"Re: Question about \"git commit -a\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-10-05T16:33:38Z","receivedAt":"2007-10-05T16:33:38Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Kristian Høgsberg writes:\n\n> I understand why people like staging and commit without -a, seeing how\n> it's faster and all,\n\nActually, commit without -a is not much faster, since it runs \"status\"\ninternally, to show it to the user when launching the editor. So, it\nstill checks for changes in the working tree.\n\n> but I have a serious problem with this practice that I haven't seen\n> brought up on the list. How do you know what you commit actually\n> works or even compiles?\n\nThat's a general problem with partial commits, and that's why I\npersonnaly don't like partial commits in general ($scm commit file1\nfile2 has the same problem, \\forall $scm).\n\nTo me, the right approach to partial commit is to stash the unwanted\nchanges, test, commit, and unstash.\n\n(side note: it would be cool to have a \"git stash --unstaged\" command,\nto put the unstaged changes aside, and match the tree to the index. A\ngood approximation for that is:\n\n$ git stash # put all aside\n$ git reset --mixed stash^2 # get back what the index used to be\n$ git add -u # and put it back into the index.\n)\n\n*But*, the cool thing with git is that you can view rather easily not\nonly what you're about to commit (git diff --cached), but also what\nyou're about _not_ to commit (git diff). So, if the unstaged changes\nare trivial enough, it can be OK (for example, Linus changes the linux\nversion in a Makefile a few commits before the release, and doesn't\nadd it to the index, to keep it as a reminder).\n\nBut I agree with your that splitting a huge patch into smaller ones\nusing just the index is bad practice, except if you intend to come\nback to each commit and test it later.\n\n-- \nMatthieu\n"},{"id":"54990","messageId":"47067F68.2080709@gmx.net","threadId":"10139","inReplyTo":"1191599763.7117.18.camel@hinata.boston.redhat.com","subject":"Re: Question about \"git commit -a\"","fromName":"Marko Macek","fromEmail":"marko.macek@gmx.net","sentAt":"2007-10-05T18:16:08Z","receivedAt":"2007-10-05T18:16:08Z","isPatch":false,"sender":{"key":"marko.macek@gmx.net","avatar":null},"body":"\n> I understand why people like staging and commit without -a, seeing how\n> it's faster and all, but I have a serious problem with this practice\n> that I haven't seen brought up on the list. How do you know what you\n> commit actually works or even compiles? The reason that I almost\n> exclusively use -a with commit is that I want to know that what I just\n> compiled and tested is what I will be committing. I don't want to just\n> commit half the files in my working copy, I want to make sure that the\n> exact state of my project that I just compiled and tested is what gets\n> into version controlled history.\n> \n> git commit -a isn't sloppy to me - eye balling some subset of your\n> working copy and committing that under the assumption that you don't\n> make mistakes and don't need to compile what you commit... that is\n> sloppy.\n\nAgreed. For this reason git-commit without -a, staging, index, ... is\nnot really interesting to me.\n\nIn CVS and subversion (which has nicer working-copy command line interface IMHO),\nI simply make a copy of the working copy, revert the non-commitable parts, build,\ncommit the minor changes, and then update the first copy. For larger projects,\nwhere this can be slow, I use diff/revert/patch.\n\nSmall checkins are nice for git-bisect, but if they don't build...\n\nMark\n"},{"id":"55003","messageId":"20071005211011.GB25125@potapov","threadId":"10139","inReplyTo":"1191599763.7117.18.camel@hinata.boston.redhat.com","subject":"Re: Question about \"git commit -a\"","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2007-10-05T21:10:11Z","receivedAt":"2007-10-05T21:10:11Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Oct 05, 2007 at 11:56:03AM -0400, Kristian Høgsberg wrote:\n> I understand why people like staging and commit without -a, seeing how\n> it's faster and all, but I have a serious problem with this practice\n> that I haven't seen brought up on the list. How do you know what you\n> commit actually works or even compiles?\n\nYou don't. Even with 'commit -a' there is no guarantee that the\nresult will compile, because you can forget to add a new file.\nIMHO, the best practice is to recompile everything step-wise in \na clean directory before you are going to publish your changes.\nIt can be done automatically by script, while you do something\nuseful, like reading this mailing-list :)\n\nDmitry\n"},{"id":"55008","messageId":"200710060843.38567.andyparkins@gmail.com","threadId":"10139","inReplyTo":"47067F68.2080709@gmx.net","subject":"Re: Question about \"git commit -a\"","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-10-06T07:43:36Z","receivedAt":"2007-10-06T07:43:36Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007, October 05, Marko Macek wrote:\n\n> In CVS and subversion (which has nicer working-copy command line\n> interface IMHO), I simply make a copy of the working copy, revert the\n> non-commitable parts, build, commit the minor changes, and then update\n> the first copy. For larger projects, where this can be slow, I use\n> diff/revert/patch.\n>\n> Small checkins are nice for git-bisect, but if they don't build...\n\nWho cares? Commits that build isn't the only reason for small commits.\n\ngit-bisect is nice and small buildable commits is something to aim for. \nHowever, there is more to software history that buildable commits.\n\nI hardly ever git-bisect, and I hardly ever checkout old revisions, however \nI read the log _all the time_. The smaller the commit and the better the \nlog message the more quickly I'll understand what was going on. In the end \neven if the commit doesn't build as long as the log message is a good \ndescription of what the commit does and that thing is an isolated change \nthen the revision has achieved its goal for me.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"55018","messageId":"alpine.LFD.0.999.0710060903310.23684@woody.linux-foundation.org","threadId":"10139","inReplyTo":"200710060843.38567.andyparkins@gmail.com","subject":"Re: Question about \"git commit -a\"","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-06T16:13:21Z","receivedAt":"2007-10-06T16:13:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 6 Oct 2007, Andy Parkins wrote:\n> \n> Who cares? Commits that build isn't the only reason for small commits.\n\nMore importantly, while it's true that you should always test all your \nchanges, quite often they really *are* obviously separate.\n\nI've mentioned this as an example lots of times, but I often tend to have \nmultiple independent things in my tree at the same time. One of the \n\"clearly independent\" ones is the fact that I historically tended to \nupdate my Makefile for the next version number several days before I do \nthe actual release, just to remind me (I used to forget to bump the \nversion number, so..).\n\nSo I often have a dirty main makefile, but that doesn't mean that I'm \ngoing to commit it until I'm ready. I want to (no - *need* to) be able to \npull and apply patches from other people despite the fact that I have some \ndirty state.\n\n[ It's not just the makefile: almost all of what I do these days is pull \n and apply patches, but I also send out suggestions to other developers \n by email, and I often end up keeping my suggestion around in my tree as \n dirty state. I could use a topic branch, but the thing is, I don't \n actually want to save it - but not only do I actually like seeing the \n \"couldn't merge due to dirty state\" because that tells me I got the fix \n back, but I like just eatign my dogfood and compiling the kernel with \n the suggestions I sent out ]\n\nSo it's quite ok to have multiple independent changes going on it the \ntree, and there's absolutely *zero* reason to think you should commit them \ntogether (quite the reverse). Maybe this isn't all that common for a \n*small* thing, but I pretty much guarantee that large projects always end \nup doing somethng like this.\n\nAnd making the *default* workflow do something bad - namely commit \neverything blindly - is not a good idea. I'd rather have the normal \nworkflow basically try to encourage many small commits, because while it's \ntrue that they may not have been tested individually, 99% of the time any \nlinkages are pretty obvious.\n\n(Side note: the *most* common failure to check stuff in completely tends \nto be one that other SCM's also have, for all the same reasons: forgetting \nto *add* a new file. I suspect the git model of \"add all new changes\" \nwhether new files or old, actually _helps_ avoid that error, but quite \nfrankly, I don't think we'll ever get away from it. It's just too easy a \nmistake to do).\n\n\t\t\tLinus\n"},{"id":"55040","messageId":"470878CB.2010609@gmx.net","threadId":"10139","inReplyTo":"20071005211011.GB25125@potapov","subject":"Re: Question about \"git commit -a\"","fromName":"Marko Macek","fromEmail":"marko.macek@gmx.net","sentAt":"2007-10-07T06:12:27Z","receivedAt":"2007-10-07T06:12:27Z","isPatch":false,"sender":{"key":"marko.macek@gmx.net","avatar":null},"body":"Dmitry Potapov wrote:\n> You don't. Even with 'commit -a' there is no guarantee that the\n> result will compile, because you can forget to add a new file.\n\nActually, it would be a good idea for commit to report an error if there\nare any new files that have not been 'added' or 'ignored' (or even \nif there are missing files that have not been 'deleted'.\n\nPerhaps I'll add this to my git wrapper scripts.\n\nEven for normal git-commit it might be nice to report an error if there are any\nunstaged files unless -a or -i option is specified.\n\nMark\n"},{"id":"55044","messageId":"E0245DA3-1B32-47C3-88F9-BF2B4AAB084F@wincent.com","threadId":"10139","inReplyTo":"47067F68.2080709@gmx.net","subject":"Re: Question about \"git commit -a\"","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-07T12:26:39Z","receivedAt":"2007-10-07T12:26:39Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 5/10/2007, a las 20:16, Marko Macek escribió:\n\n> In CVS and subversion (which has nicer working-copy command line \n> interface IMHO),\n> I simply make a copy of the working copy, revert the non-commitable \n> parts, build,\n> commit the minor changes, and then update the first copy. For \n> larger projects,\n> where this can be slow, I use diff/revert/patch.\n\nThis sounds painful compared to Dmitry's method (pasted below) if you \ncare about all published changes being buildable and passing all the \ntests...\n\nEl 5/10/2007, a las 23:10, Dmitry Potapov escribió:\n\n> IMHO, the best practice is to recompile everything step-wise in\n> a clean directory before you are going to publish your changes.\n> It can be done automatically by script, while you do something\n> useful, like reading this mailing-list :)\n\nCheers,\nWincent\n"},{"id":"55051","messageId":"37fcd2780710070750g23deb2e1q1b9a7e5c555a44bf@mail.gmail.com","threadId":"10139","inReplyTo":"470878CB.2010609@gmx.net","subject":"Re: Question about \"git commit -a\"","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2007-10-07T14:50:56Z","receivedAt":"2007-10-07T14:50:56Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On 10/7/07, Marko Macek wrote:\n> Dmitry Potapov wrote:\n> > You don't. Even with 'commit -a' there is no guarantee that the\n> > result will compile, because you can forget to add a new file.\n>\n> Actually, it would be a good idea for commit to report an error if there\n> are any new files that have not been 'added' or 'ignored'\n\nIf it is good for you, you can add this check to your pre-commit hook.\nHowever, I don't like your idea at all. Sometimes, you do want to have\nsome file that is not 'added' or 'ignored' as a reminder that you have\nsomething else to do. IMHO, git acts in the most reasonable way in this\nrespect. When you say 'commit -a' and you have some files not added,\nit will show you all untracked files in your editor when you type a\ncommit message. So, it is more difficult to forget to add a new file\nwith git than with many other version control systems.\n\n> (or even\n> if there are missing files that have not been 'deleted'.\n\nActually, 'commit -a' will automatically delete all missing files.\nIMHO, it is the right thing to do.\n\nDmitry\n"},{"id":"55063","messageId":"Pine.LNX.4.64.0710071724330.4174@racer.site","threadId":"10139","inReplyTo":"470878CB.2010609@gmx.net","subject":"Re: Question about \"git commit -a\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-07T16:26:54Z","receivedAt":"2007-10-07T16:26:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 7 Oct 2007, Marko Macek wrote:\n\n> Dmitry Potapov wrote:\n> > You don't. Even with 'commit -a' there is no guarantee that the\n> > result will compile, because you can forget to add a new file.\n> \n> Actually, it would be a good idea for commit to report an error if there \n> are any new files that have not been 'added' or 'ignored' (or even if \n> there are missing files that have not been 'deleted'.\n\nIt is no error.\n\nAnd it is reported. That is the whole _point_ of having git status output \nboth changed-but-not-staged and untracked files.\n\nOf course, you only see that when you do not provide the message within \nthe editor, but from the command line. But then chances are that your \nmessage is too short anyway.\n\nCiao,\nDscho\n"}]}