{"thread":{"id":"20191","subject":"Why is it important to learn git?","startedAt":"2009-07-22T05:08:31Z","lastAt":"2009-08-04T14:09:26Z","messageCount":10,"participants":["Tim Harper","Thomas Rast","Sverre Rabbelier","Scott Chacon","Dmitry Potapov","Jakub Narebski","Allan Kelly","Jeff King","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"118449","messageId":"e1a5e9a00907212208t10a071d0oe59a39b357a1111a@mail.gmail.com","threadId":"20191","inReplyTo":null,"subject":"Why is it important to learn git?","fromName":"Tim Harper","fromEmail":"timcharper@gmail.com","sentAt":"2009-07-22T05:08:31Z","receivedAt":"2009-07-22T05:08:31Z","isPatch":false,"sender":{"key":"timcharper@gmail.com","avatar":"https://gravatar.com/avatar/1a2e0c06c7862ff065ee6b1d53195333a5a0577c040ecb2856a150d8e0b00ecd?d=mp&s=160"},"body":"Hi all,\n\nI'm preparing to teach a workshop on git, and would like to know how\nother people benefit from the advanced features of git.  So, if you're\nfeeling kind enough to share a few minutes to respond (which I will\nreceive with gratitude):\n\nHow has mastering the advanced features of git helped you to be a\nbetter programmer?\n"},{"id":"118454","messageId":"200907220952.27385.trast@student.ethz.ch","threadId":"20191","inReplyTo":"e1a5e9a00907212208t10a071d0oe59a39b357a1111a@mail.gmail.com","subject":"Re: Why is it important to learn git?","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-22T07:52:26Z","receivedAt":"2009-07-22T07:52:26Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Tim Harper wrote:\n> \n> How has mastering the advanced features of git helped you to be a\n> better programmer?\n\nI came from SVN, and I guess the most important change for me was:\n\n  Learning to make nice, reviewable, working, one-change-per-revision\n  commits.\n\nThis must be enforced by social pressure of course, but 'add --patch',\n'commit --amend', 'rebase --interactive' and some others make it very\neasy to actually do it even when working on a series of changes.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"118475","messageId":"fabb9a1e0907221115x212c4b52q47cac29cf0336fc@mail.gmail.com","threadId":"20191","inReplyTo":"200907220952.27385.trast@student.ethz.ch","subject":"Re: Why is it important to learn git?","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-07-22T18:15:10Z","receivedAt":"2009-07-22T18:15:10Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Jul 22, 2009 at 07:52, Thomas Rast<trast@student.ethz.ch> wrote:\n>  Learning to make nice, reviewable, working, one-change-per-revision\n>  commits.\n\nI very much agree with those values, but also\n\n  Commit early, commit often\n\nIt's very convenient to be able to go back to/diff with a previous\nversion later on, running 'git commit -am \"got x half-working\"' takes\nonly a few seconds, but can save hours later on when you got x\ntotally-not-working-at-all-anymore.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"118477","messageId":"d411cc4a0907221131q28ffb24av8715c4497f50deb3@mail.gmail.com","threadId":"20191","inReplyTo":"e1a5e9a00907212208t10a071d0oe59a39b357a1111a@mail.gmail.com","subject":"Re: Why is it important to learn git?","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2009-07-22T18:31:00Z","receivedAt":"2009-07-22T18:31:00Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey,\n\nOn Tue, Jul 21, 2009 at 10:08 PM, Tim Harper<timcharper@gmail.com> wrote:\n> Hi all,\n>\n> I'm preparing to teach a workshop on git, and would like to know how\n> other people benefit from the advanced features of git.  So, if you're\n> feeling kind enough to share a few minutes to respond (which I will\n> receive with gratitude):\n>\n> How has mastering the advanced features of git helped you to be a\n> better programmer?\n\nI think the biggest gain Git gives many developers over other VCSs\n(even other DVCSs) is the lightweight branching flexibility and easy\nmerging.  In Git, lightweight branches or topic branches are used in\nmuch the same way that patch queuing tools like Hg's mq extension or\nquilt, but I think most users find them much, much easier to use and\nunderstand and often less error prone.  Using branches as silos\ndedicated to a single work topic and being able to easily keep them\nseparated until you are ready to apply them to a main line of work\n(such as merging with your master branch) is very powerful and is done\nvia a very simple and understandable existing paradigm of branches\nrather than trying to learn a whole new command set of patching.  This\nallows for fast and simple context switching and work unit isolation\nthat both very definitively changes most developers workflows in ways\nthat were completely impossible in SVN or Perforce or what-have-you.\n\nHope that helps.  If you need any material for your workshop, I have a\nnumber of slides (Keynote and PDF) for presentations I have given at:\n\nhttp://github.com/schacon/git-presentations\n\nYou can also get the PDF of the slides of the tutorial I gave at OSCON\nyesterday on Git here:\n\nhttp://en.oreilly.com/oscon2009/public/schedule/detail/7953\n\nLet me know if there is anything else I can do to help.\n\nThanks,\nScott\n"},{"id":"118485","messageId":"20090722210738.GA25324@dpotapov.dyndns.org","threadId":"20191","inReplyTo":"e1a5e9a00907212208t10a071d0oe59a39b357a1111a@mail.gmail.com","subject":"Re: Why is it important to learn git?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-07-22T21:07:39Z","receivedAt":"2009-07-22T21:07:39Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Jul 21, 2009 at 11:08:31PM -0600, Tim Harper wrote:\n> \n> How has mastering the advanced features of git helped you to be a\n> better programmer?\n\nI don't think that features itself make as big difference as the fact\nGit provides you much more flexibility in choosing a more appropriate\nworkflow than you have with any centralized VCS. (Yes, you will still\nfind many Git features handy even if you work with it as you did with\nCVS, but you will miss most benefits of Git).\n\nTo really understand what benefits Git offers, you have to realize first\nwhat is wrong CVS and CVS-like VCSes. Unfortunately, it is difficult to\nexplain just in a few words. Some implementation deficiency of CVS is\nobvious (and it was addressed in some CVS clones like Subversion), but\nmore fundamental problems are far less obvious even for people who used\nCVS for many years.\n\nTo be fair to CVS, it is far from the worst VCS. There are some insane\nlock-based VCS, which were so painful to use (mostly due to these\nexclusive locks but often due to some other insanity too) that anyone\nwho worked with may think about CVS as a really nice system...\n\nIn some way, CVS was really revolutionary for its time, because it used\nthe copy-modify-merge paradigm instead of excluding locking, which was\ndominant before the CVS era. Those exclusive locks not only could not\nwork over the Internet, they were so excruciatingly annoying even if\neveryone was sitting in the same room... Despite some initial skepticism\nabout essentially the lock-free VCS, I think it is safe to say now that\nthe copy-modify-merge paradigm won. Period.\n\nHowever, if you look at the support of this paradigm in CVS and other\ncentralized VCSes, it is very limited in every aspect:\n- copy: you can have a copy only one revision. (it may not be a big\n  issue unless you like to work offline and to look at history).\n- modify: there is no problem with modification itself, but you cannot\n  save your changes without committing that to the official repo, which\n  is not such a good thing if they are not ready yet or were not reviewed\n  properly.\n- merge: well.. I don't think there is any sane person who enjoyed\n  merging branches in CVS... The only merge that was _relatively_ easy\n  to do was merging your worktree with the upstream. Even that is not\n  perfect in CVS, because you cannot save your changes before merge. So,\n  if you made a mistake during 'cvs update', you risk to losing your\n  work... Also, there is no possibility to review the merge later or to\n  delegate to someone else when its resolution happens to be tricky...\n\nThe above limitations have further consequences with negatively affect\nco-operation among developers. For instance, it is very difficult to\norganize the review process with any centralized VCS. Typically, a\nreview process may require saving and share your work with reviewer\nwithout committing it to the central repo. Also, this work should be\nsplit into logical steps to make review easier. The only way to do that\nwith a centralized VCS is to use some patch management system on top of\nit.... and at that point you may ask whether you want to learn two\nsystems with overlapping functionality and not so well integrated with\neach other?\n\nAnother important reason why feature branches are so useful is that they\nallow to postpone the decision about integration of some feature to the\nmaster branch to the time when you convince that it is ready and useful.\nIn a \"centralized\" workflow, people often commit as they progress to\ntheir goal, but some ideas may not so good as they initially appeared.\nAt the time when you realize that, your changes already intervened with\nother people changes. There is no easy way to remove them cleanly. And,\nsome work even if it is useful may be not ready to the time when you\nplanned to realize a new version. This results in unnecessary delays in\nrelease.\n\nThere are more problems with the \"centralized\" workflow used by CVS and\nalike. They may be not very noticeable on small projects, but it tends\nto get worse as any project growths over time.\n\n\nSo, the main advantage of Git is not in the number of features (and Git\nhas plenty of them despite of efforts to limit them to only truly useful\nfor many users), but its conceptual wholeness and flexibility, which\nallows you to choose the appropriate workflow for your needs.\n\n\nDmitry\n"},{"id":"118493","messageId":"m3my6wbdfs.fsf@localhost.localdomain","threadId":"20191","inReplyTo":"20090722210738.GA25324@dpotapov.dyndns.org","subject":"Re: Why is it important to learn git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-07-22T21:44:23Z","receivedAt":"2009-07-22T21:44:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dmitry Potapov <dpotapov@gmail.com> writes:\n\n> On Tue, Jul 21, 2009 at 11:08:31PM -0600, Tim Harper wrote:\n> > \n> > How has mastering the advanced features of git helped you to be a\n> > better programmer?\n> \n> I don't think that features itself make as big difference as the fact\n> Git provides you much more flexibility in choosing a more appropriate\n> workflow than you have with any centralized VCS. (Yes, you will still\n> find many Git features handy even if you work with it as you did with\n> CVS, but you will miss most benefits of Git).\n> \n> To really understand what benefits Git offers, you have to realize first\n> what is wrong CVS and CVS-like VCSes. Unfortunately, it is difficult to\n> explain just in a few words. Some implementation deficiency of CVS is\n> obvious (and it was addressed in some CVS clones like Subversion), but\n> more fundamental problems are far less obvious even for people who used\n> CVS for many years.\n\nSee also my answer for \"Difference between GIT and CVS\" question\nat StackOverflow:\n\n  http://stackoverflow.com/questions/802573/difference-between-git-and-cvs/824241#824241\n \n> To be fair to CVS, it is far from the worst VCS. There are some insane\n> lock-based VCS, which were so painful to use (mostly due to these\n> exclusive locks but often due to some other insanity too) that anyone\n> who worked with may think about CVS as a really nice system...\n\nBy the way, even if CVS didn't implement support for file renames and\ncopying, at least it provides support for file deletion (as opposed to\n*khem* SourceSafe).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"118496","messageId":"m3iqhkbdb9.fsf@localhost.localdomain","threadId":"20191","inReplyTo":"fabb9a1e0907221115x212c4b52q47cac29cf0336fc@mail.gmail.com","subject":"Re: Why is it important to learn git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-07-22T21:47:05Z","receivedAt":"2009-07-22T21:47:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n> On Wed, Jul 22, 2009 at 07:52, Thomas Rast<trast@student.ethz.ch> wrote:\n\n> >  Learning to make nice, reviewable, working, one-change-per-revision\n> >  commits.\n> \n> I very much agree with those values, but also\n> \n>   Commit early, commit often\n \nI also find commit message convention: \"short one-line description,\nseparated by empty line, then more detailed description\" to be very\nuseful (git tools assume and expect this convention).  It helps\nkeeping changesets / commits small; if you can't write oneline summary\nof commit, it is probably too large :-)\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"118500","messageId":"9586f3420907221450p6b9df86cy62e1832d06150286@mail.gmail.com","threadId":"20191","inReplyTo":"m3my6wbdfs.fsf@localhost.localdomain","subject":"Re: Why is it important to learn git?","fromName":"Allan Kelly","fromEmail":"allankelly@gmail.com","sentAt":"2009-07-22T21:50:37Z","receivedAt":"2009-07-22T21:50:37Z","isPatch":false,"sender":{"key":"allankelly@gmail.com","avatar":"https://gravatar.com/avatar/c62021c01204c1e0c91084a96d4c16f19d394d3e67f6f51c707686da1d59cb64?d=mp&s=160"},"body":"Has anyone done a presentation on this (very interesting) subject with examples?\n\nWhat's good about this practice/pattern?\nWhat's bad about that practice/pattern?\n\nI ask because if not, I'd like to - with your help!\n\nCheers, al.\n\n2009/7/22 Jakub Narebski <jnareb@gmail.com>:\n> Dmitry Potapov <dpotapov@gmail.com> writes:\n>\n>> On Tue, Jul 21, 2009 at 11:08:31PM -0600, Tim Harper wrote:\n>> >\n>> > How has mastering the advanced features of git helped you to be a\n>> > better programmer?\n>>\n>> I don't think that features itself make as big difference as the fact\n>> Git provides you much more flexibility in choosing a more appropriate\n>> workflow than you have with any centralized VCS. (Yes, you will still\n>> find many Git features handy even if you work with it as you did with\n>> CVS, but you will miss most benefits of Git).\n>>\n>> To really understand what benefits Git offers, you have to realize first\n>> what is wrong CVS and CVS-like VCSes. Unfortunately, it is difficult to\n>> explain just in a few words. Some implementation deficiency of CVS is\n>> obvious (and it was addressed in some CVS clones like Subversion), but\n>> more fundamental problems are far less obvious even for people who used\n>> CVS for many years.\n>\n> See also my answer for \"Difference between GIT and CVS\" question\n> at StackOverflow:\n>\n>  http://stackoverflow.com/questions/802573/difference-between-git-and-cvs/824241#824241\n>\n>> To be fair to CVS, it is far from the worst VCS. There are some insane\n>> lock-based VCS, which were so painful to use (mostly due to these\n>> exclusive locks but often due to some other insanity too) that anyone\n>> who worked with may think about CVS as a really nice system...\n>\n> By the way, even if CVS didn't implement support for file renames and\n> copying, at least it provides support for file deletion (as opposed to\n> *khem* SourceSafe).\n>\n> --\n> Jakub Narebski\n> Poland\n> ShadeHawk on #git\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"118544","messageId":"20090723050013.GA9189@coredump.intra.peff.net","threadId":"20191","inReplyTo":"200907220952.27385.trast@student.ethz.ch","subject":"Re: Why is it important to learn git?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-07-23T05:00:13Z","receivedAt":"2009-07-23T05:00:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 22, 2009 at 09:52:26AM +0200, Thomas Rast wrote:\n\n> > How has mastering the advanced features of git helped you to be a\n> > better programmer?\n> \n> I came from SVN, and I guess the most important change for me was:\n> \n>   Learning to make nice, reviewable, working, one-change-per-revision\n>   commits.\n\nSame here. Git makes this easy to do. But it also makes me _want_ to do\nit, because I benefit later from the advanced history investigation tools\nlike bisecting, pickaxe, blame, and even just decent visualization like\ngitk that is lacking in other systems.\n\nAnd of course if your workflow is based on reviewing patches (like for\ngit itself), then it is almost necessary.\n\n-Peff\n"},{"id":"119498","messageId":"4A784116.2050508@op5.se","threadId":"20191","inReplyTo":"200907220952.27385.trast@student.ethz.ch","subject":"Re: Why is it important to learn git?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-08-04T14:09:26Z","receivedAt":"2009-08-04T14:09:26Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Thomas Rast wrote:\n> Tim Harper wrote:\n>> How has mastering the advanced features of git helped you to be a\n>> better programmer?\n> \n> I came from SVN, and I guess the most important change for me was:\n> \n>   Learning to make nice, reviewable, working, one-change-per-revision\n>   commits.\n> \n\nSeconded. During the CVS days, noone bothered about history, but with\ngit a it's a veritable goldmine of important information, so it's\nimportant to keep it clean with minimal changesets.\n\nOne of our developers was very sloppy about this until he ended up\nwith a bisection run landing him on a commit that fixed no less\nthan seven different issues. He spent four days debugging it and\nfinally had to resort to breaking the issues up and creating the\ncommits as they should have been on a temporary side-branch and\nthen bisecting that side-branch. Having done that, he spotted the\nerror in about 15 minutes. After some swearing, he finally saw the\nlight. He's actually a happier person now, since bugs that take a\nlong time to solve upset him quite enormously and now he never runs\ninto any :-)\n\nApart from that, the various ways of cooperating over large distances\n(easy branching + merging, patch sending/applying utilities) are a\nhuge benefit for us.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"}]}