9 ms·

Git: The Lean, Mean, Distributed Machine

58 points by r11t 17y ago

wglb 17y ago
This is a good introduction to Git. Some of the pictures chosen to illustrate points are hilarious, like the smoking angel, or the RCS shack.
gvb 17y ago
Another advantage of DVCS that wasn't mentioned in the slide deck is that, with git (and other DVCSes), you are always working in a revision controlled arena. Git's got your back. When I used RCS, I was always working in a revision controlled arena - all my changes were revision controlled, assuming I checked them in... and after the first or second disaster, I learned to check things in. Frequently. When I used CVS/SVN, I lost the ability to always work in a revision controlled arena (theoretically I still had the ability, but doing it was such a hassle that it simply did not happen). I ended up checking out a copy from SVN and then locally revision controlling my changes in RCS. Ugly. Working without git is like driving without seat belts. You can do it and probably nothing bad will happen... but if something bad does happen, it is the difference between walking away a bit sore and an extended hospital visit.
- tolenka 17y ago
  I can't say I understand your point. With svn, I commit often, as long as the code builds and my own unit tests pass. If I need to make a lot of breaking changes, I use 'svn cp' to create a branch and then I can still leverage svn's merge tracking in keeping that branch up-to-date. This seems like the same way I use git/hg, but without worrying about excessively divergent local/remote branches across machines -- I can see your branches, you can see mine, they're all centrally accessible by definition.
  - gvb 17y ago
    If you own the SVN repository, I agree, it works well enough. However, if you don't have write privileges to the repository or if it is a shared repository with a lot of other people, it becomes much more difficult. If you don't have write privileges into the SVN repository, you have no ability to revision control your changes without creating a tracking repository of your own. Creating and maintaining a tracking repository is a hassle, especially compared to a DVCS where that is the normal operation. If there are a lot of people with write access into your SVN repository, creating branches doesn't scale well because all the branches are public. Creating a SVN branch for every experiment rapidly gets out of hand. Again, you can create a separate tracking SVN repository (hassle) or you can use branches, but it is nowhere near as easy as with DCVSes. The big difference with DCVSes is that scaling across lots of developers is not a problem, branches are strongly encouraged, and merging works really well.
    - tolenka 17y ago
      If you don't have write privileges into the SVN repository, you have no ability to revision control your changes without creating a tracking repository of your own. This is fairly unique to open source software -- it's not something that occurs in an organization, and should only occur when a user without commit access is doing large-scale modifications to a project. Unfortunately, the functionality often used to maintain divergent forks where individuals fail to push small hacks/changes immediately back to their origin project. Creating a SVN branch for every experiment rapidly gets out of hand. Out of hand how? I've worked in organizations where every single feature received a developer specific branch (eg, branches/tolenka-feature-xyz) and never ran into trouble. The big difference with DCVSes is that scaling across lots of developers is not a problem, branches are strongly encouraged, and merging works really well. Given merge tracking, merging works more or less the same as a DVCS. As far as scaling across developers, I'm not sure what the issue is.
startingup 17y ago
Can anyone compare Git vs Mercurial? This decision is coming up for us, and would appreciate the input.
- silentbicycle 17y ago
  Here's my experience with each. I'm biased and stubborn here, but in ways that may or may not be relevant to you. Your circumstances will differ, so take any advice about this with a grain of salt. I've used distributed VC systems for quite a while, at least in the small. I find VC systems, databases, and the like verrrry interesting (due to a past life working in libraries), and an acquaintance of mine was the primary author of Monotone. I had already been keeping my home directory and /etc in svn, but that sounded far more interesting (it was also a full backup!). I tried it, and found using repository-as-a-whole versions more convenient than per-file versions. Later, I tried out hg, and felt it had a nicer interface / was easier to set up for common operations. (mtn assumed you cared to set up strong crypto auth for everything.) I was quite happy with Mercurial - it's a good system. After using hg for a while (nine months or so?) I tried out git. It was still rough around the edges (the interface and documentation have since gotten better), but it had one major feature that stuck out - its ability to nonchalantly create and shuffle between several local, topical working branches in the same repository. To my knowledge, Mercurial still doesn't have a comparable feature, since their decisions about the core data structures make it awkward -- git saves the repo in terms of data snapshots, while hg saves the diffs (or perhaps vice versa, I forget). There was a major release where the hg team introduced "bookmarks", which were an attempts to emulate the git branching model, but you still had to be careful about copying them from one repo to another, etc. It had different trade-offs. I stopped paying attention around then. (If hg has since gained these, it would be a major point in its favor.) That sounds overly negative towards hg, though. A major con of git is that the system is heavily skewed towards running on Unix. If you install it on Windows, it uses vim as the default editor for comments, it assumes you're used to man pages, etc. As a whole, the native behavior of the platform is an afterthought. Lots of little Unix-isms. Now, I can't blame them - I use OpenBSD at home, and strongly prefer old-school Unix in general. Also, developing any kind of system with the niceties that Unix provides and then porting it to Windows later is a big pain. Still, Mercurial's releases have consistently seemed to more evenly support Windows. I develop for Windows at work (in a field involving high-performance graphics and associated hardware), and, for my own circumstances, would choose Mercurial over git. Again, I should stress they're both a landslide better than any other systems I've seen. Also, mercurial seems to place more emphasis on being simple for basic use, yet having a clean foundation for adding extensions. I haven't written any, or looked at it in a while, but it seemed like a good example of the different design styles - git was more powerful but scruffy, while mercurial was clean and more concerned with usability. (Whether this is an emergent property of git being written in C and shell scripts vs mercurial in Python with hotspots in C would be an interesting debate.) I still use git for my home directory and personal projects, though most systems' flaws aren't a big deal for smaller projects. Feel free to experiment. If you're doing research prior to committing to one or the other for a massive project, switching really isn't a big deal until you have branches with months of churn. Unless you're working on the Linux kernel or an equally massive project (unlikely), it'd be far easier (in isolation - not counting retraining) to just pick one, use it for a couple months, articulate pros and cons, then switch and compare. They have quite a bit in common, and either would be vastly preferable to svn (ack!) or perforce (ACK!!!). You can't make an informed decision without trying either, and they're both quite good. I looked into Darcs as another system that had interesting features and a pretty nice interface, but given the problems with bootstrapping an even remotely recent version of GHC on BSD (http://hackage.haskell.org/trac/ghc/ticket/1346 http://hackage.haskell.org/trac/ghc/ticket/1346), there's no way in hell I'd depend on Haskell for something as fundamental as VC. Also, weird web2.0 juice nonwithstanding, it's a version control system, not a religion. It's a means to an end. You (everyone), you're using it because you're writing something, not because you're trying to be seen scribbling deep thoughts in a damn moleskine notebook.
xtho 17y ago
84MB download for a dia show of cc eye-catching but nevertheless offtopic images. Wow! Sometimes I really wish people would stick to that dull bullet points style of presentation -- in at least half of their slides.
- philwelch 17y ago
  Actually, I think this style would have been pretty effective if I was watching the guy give his talk.
RiderOfGiraffes 17y ago
15:00 Zulu time: URL is down for me: Error: 500. Will check later.
GrandMasterBirt 17y ago
One thing I dislike about the presentation is it does not give credit where credit is due. BitMover wrote BitKeeper (I use it atm at work) which was the predecessor of mercurial and git. Naturally there were issues with being proprietary till it pissed off the right people causing them to create a new VCS based on BK. BitKeeper is... pretty damn slow compared to Git. But it was the innovation. Also if he mentioned clearcase's performance it would be obvious that Clearcase is a hut made out of good intentions (we didnt even use sticks at that point).

58 points by r11t 17y ago

wglb 17y ago

This is a good introduction to Git. Some of the pictures chosen to illustrate points are hilarious, like the smoking angel, or the RCS shack.

gvb 17y ago

Another advantage of DVCS that wasn't mentioned in the slide deck is that, with git (and other DVCSes), you are always working in a revision controlled arena. Git's got your back. When I used RCS, I was always working in a revision controlled arena - all my changes were revision controlled, assuming I checked them in... and after the first or second disaster, I learned to check things in. Frequently. When I used CVS/SVN, I lost the ability to always work in a revision controlled arena (theoretically I still had the ability, but doing it was such a hassle that it simply did not happen). I ended up checking out a copy from SVN and then locally revision controlling my changes in RCS. Ugly. Working without git is like driving without seat belts. You can do it and probably nothing bad will happen... but if something bad does happen, it is the difference between walking away a bit sore and an extended hospital visit.

tolenka 17y ago
I can't say I understand your point. With svn, I commit often, as long as the code builds and my own unit tests pass. If I need to make a lot of breaking changes, I use 'svn cp' to create a branch and then I can still leverage svn's merge tracking in keeping that branch up-to-date. This seems like the same way I use git/hg, but without worrying about excessively divergent local/remote branches across machines -- I can see your branches, you can see mine, they're all centrally accessible by definition.
- gvb 17y ago
  If you own the SVN repository, I agree, it works well enough. However, if you don't have write privileges to the repository or if it is a shared repository with a lot of other people, it becomes much more difficult. If you don't have write privileges into the SVN repository, you have no ability to revision control your changes without creating a tracking repository of your own. Creating and maintaining a tracking repository is a hassle, especially compared to a DVCS where that is the normal operation. If there are a lot of people with write access into your SVN repository, creating branches doesn't scale well because all the branches are public. Creating a SVN branch for every experiment rapidly gets out of hand. Again, you can create a separate tracking SVN repository (hassle) or you can use branches, but it is nowhere near as easy as with DCVSes. The big difference with DCVSes is that scaling across lots of developers is not a problem, branches are strongly encouraged, and merging works really well.
  - tolenka 17y ago
    If you don't have write privileges into the SVN repository, you have no ability to revision control your changes without creating a tracking repository of your own. This is fairly unique to open source software -- it's not something that occurs in an organization, and should only occur when a user without commit access is doing large-scale modifications to a project. Unfortunately, the functionality often used to maintain divergent forks where individuals fail to push small hacks/changes immediately back to their origin project. Creating a SVN branch for every experiment rapidly gets out of hand. Out of hand how? I've worked in organizations where every single feature received a developer specific branch (eg, branches/tolenka-feature-xyz) and never ran into trouble. The big difference with DCVSes is that scaling across lots of developers is not a problem, branches are strongly encouraged, and merging works really well. Given merge tracking, merging works more or less the same as a DVCS. As far as scaling across developers, I'm not sure what the issue is.

startingup 17y ago

Can anyone compare Git vs Mercurial? This decision is coming up for us, and would appreciate the input.

silentbicycle 17y ago
Here's my experience with each. I'm biased and stubborn here, but in ways that may or may not be relevant to you. Your circumstances will differ, so take any advice about this with a grain of salt. I've used distributed VC systems for quite a while, at least in the small. I find VC systems, databases, and the like verrrry interesting (due to a past life working in libraries), and an acquaintance of mine was the primary author of Monotone. I had already been keeping my home directory and /etc in svn, but that sounded far more interesting (it was also a full backup!). I tried it, and found using repository-as-a-whole versions more convenient than per-file versions. Later, I tried out hg, and felt it had a nicer interface / was easier to set up for common operations. (mtn assumed you cared to set up strong crypto auth for everything.) I was quite happy with Mercurial - it's a good system. After using hg for a while (nine months or so?) I tried out git. It was still rough around the edges (the interface and documentation have since gotten better), but it had one major feature that stuck out - its ability to nonchalantly create and shuffle between several local, topical working branches in the same repository. To my knowledge, Mercurial still doesn't have a comparable feature, since their decisions about the core data structures make it awkward -- git saves the repo in terms of data snapshots, while hg saves the diffs (or perhaps vice versa, I forget). There was a major release where the hg team introduced "bookmarks", which were an attempts to emulate the git branching model, but you still had to be careful about copying them from one repo to another, etc. It had different trade-offs. I stopped paying attention around then. (If hg has since gained these, it would be a major point in its favor.) That sounds overly negative towards hg, though. A major con of git is that the system is heavily skewed towards running on Unix. If you install it on Windows, it uses vim as the default editor for comments, it assumes you're used to man pages, etc. As a whole, the native behavior of the platform is an afterthought. Lots of little Unix-isms. Now, I can't blame them - I use OpenBSD at home, and strongly prefer old-school Unix in general. Also, developing any kind of system with the niceties that Unix provides and then porting it to Windows later is a big pain. Still, Mercurial's releases have consistently seemed to more evenly support Windows. I develop for Windows at work (in a field involving high-performance graphics and associated hardware), and, for my own circumstances, would choose Mercurial over git. Again, I should stress they're both a landslide better than any other systems I've seen. Also, mercurial seems to place more emphasis on being simple for basic use, yet having a clean foundation for adding extensions. I haven't written any, or looked at it in a while, but it seemed like a good example of the different design styles - git was more powerful but scruffy, while mercurial was clean and more concerned with usability. (Whether this is an emergent property of git being written in C and shell scripts vs mercurial in Python with hotspots in C would be an interesting debate.) I still use git for my home directory and personal projects, though most systems' flaws aren't a big deal for smaller projects. Feel free to experiment. If you're doing research prior to committing to one or the other for a massive project, switching really isn't a big deal until you have branches with months of churn. Unless you're working on the Linux kernel or an equally massive project (unlikely), it'd be far easier (in isolation - not counting retraining) to just pick one, use it for a couple months, articulate pros and cons, then switch and compare. They have quite a bit in common, and either would be vastly preferable to svn (ack!) or perforce (ACK!!!). You can't make an informed decision without trying either, and they're both quite good. I looked into Darcs as another system that had interesting features and a pretty nice interface, but given the problems with bootstrapping an even remotely recent version of GHC on BSD (http://hackage.haskell.org/trac/ghc/ticket/1346 http://hackage.haskell.org/trac/ghc/ticket/1346), there's no way in hell I'd depend on Haskell for something as fundamental as VC. Also, weird web2.0 juice nonwithstanding, it's a version control system, not a religion. It's a means to an end. You (everyone), you're using it because you're writing something, not because you're trying to be seen scribbling deep thoughts in a damn moleskine notebook.

xtho 17y ago

84MB download for a dia show of cc eye-catching but nevertheless offtopic images. Wow! Sometimes I really wish people would stick to that dull bullet points style of presentation -- in at least half of their slides.

philwelch 17y ago
Actually, I think this style would have been pretty effective if I was watching the guy give his talk.

RiderOfGiraffes 17y ago

15:00 Zulu time: URL is down for me: Error: 500. Will check later.

GrandMasterBirt 17y ago

One thing I dislike about the presentation is it does not give credit where credit is due. BitMover wrote BitKeeper (I use it atm at work) which was the predecessor of mercurial and git. Naturally there were issues with being proprietary till it pissed off the right people causing them to create a new VCS based on BK. BitKeeper is... pretty damn slow compared to Git. But it was the innovation. Also if he mentioned clearcase's performance it would be obvious that Clearcase is a hut made out of good intentions (we didnt even use sticks at that point).