8 ms·

Git is cheap

113 points by beghbali 14y ago

campo 14y ago
I absolutely agree with this. I recently started working on a small web app as a side project. I was dealing with a lot of elements that were new to me and was constantly pushing the limits of my knowledge and breaking things. I realized I wasn't using the power git provided me with branches. Once I started branching things got quicker and more effective because I could bounce between tasks without affecting my deployment (master branch). In five days of frantic coding using git branching I now have a clean easy deployment of about 750 lines, which I iterated on through four different branches and, probably over 3000 lines of code. It's not perfect, but it's eliminated any apprehension about aggressively changing my application, and made me far more ambitious. I feel great about it.
- th0ma5 14y ago
  I've had a similar feeling of empowerment, although less structured. With hobby projects where sometimes I realize I was thinking all wrong about a certain solution, I'll just check in what I have and commence the deleting of large blocks. Occasionally I'll go back and find something that maybe was a good idea, but for the most part, having an excuse to part ways with bad ideas has alone been really great.
  - campo 14y ago
    That's great, reducing the barrier to entry for new projects allows for more experimentation. More experimentation increases the likelihood you'll stumble upon something you really like! What I meant to say more clearly is that I probably iterated through the creation of that web application so quickly because in five days I committed to git 75 times. In my time at Microsoft I don't know that I would have made 75 commits in a year, and creating new branches was very costly. I got numbers on my git repository by using GitStats: http://gitstats.sourceforge.net/ http://gitstats.sourceforge.net/
rkangel 14y ago
He compares it to SVN, but makes a classic error. In SVN branches and commits are just as cheap as in git (albeit marginally slower to create usually). It's the merges that are expensive. It's there that git wins, with it's better understanding of how content moves around, and the ability of the merge tool to see the history and identify the common ancestor.
- _ikke_ 14y ago
  Branching in SVN is not cheap. It basically has to copy the entire directory structure into a new subdirectory (branches directory). In git, it just creates one file with a 40 byte hex.
  - rkangel 14y ago
    Errr, no - while that's what you see in the directory tree, that's not how it's done internally. SVN has a data model where multiple paths in the repo tree can point to the same underlying file object, so a branch requires no file copies, just updating what the directory tree looks like. Even that is done in a very efficient way. It might not quite be 40 bytes, but it is negligibly small. This technique is in fact extremely similar to how Git works.
  - andrewaylett 14y ago
    Server-side, that's cheap -- it doesn't actually copy any data. Client-side, it's also cheap: you `svn switch` to the new branch, which is identical to your old branch, so only minimal housekeeping on disk (just like git).
- Peaker 14y ago
  Beyond branches being expensive, even commits in svn are expensive. They publish immediately, which requires proof-reading, more testing, before each commit. This means there's an incentive to wait with commits. Even if you do commit to a branch, where publishing is less of a problem, you still might regret a typo in the commit, which cannot (easily) be retroactively fixed whereas in git you can fix your private/unpublished commits as much as you'd like with virtually no drawbacks.
deleted 14y ago
[deleted]
prawks 14y ago
As this is a positive article about git, if the OP reads this, I'd suggest using the word "inexpensive" next time. Cheap often has a negative connotation that something is low-cost at the expense of quality. Just a pet peeve. Git is most certainly not cheaply made.
- override 14y ago
  Its a title to move eyes on HN, nothing more.
- kfinley 14y ago
  Yes, but the phrase "x is cheap" often means -- just use it. "x is inexpensive" doesn't have the same connotation. E.g. "memory is cheap"
- Cyranix 14y ago
  I chose the exact same word "cheap" in a tutorial presentation that I made for new hires and co-op students at my current company. No confusion registered in the audience so far.
- _delirium 14y ago
  I had sort of the same reaction, but it's one of those language pragmatics that seems heavily dependent on context. "Git is cheap" has the first reading to me with the cheap-crappy-gadget connotation, and I only get the intended meaning on the 2nd wave. But if you said "Git branching is cheap", I read that one as intended immediately.
skrebbel 14y ago
I strongly half-agree here. Commit early, hell yeah! Branch often, umm, no. I feel that the excellent branching features of modern DVCSes have made people lazy and afraid to confront the inherent concurrent nature of working in parallel with people on the same codebase. Sure, if you're a 200 person team, there might be no way around it some decent branching setup. But don't forget: every feature branch means postponing continuous integration. Continuous integration is the core of any productive and effective agile-ish team. Daily standups are nice, backlogs are lovely, but without continuous integration you can't get that design-develop-test cycle short enough to deploy/demo early and often. Therefore, when working on a product or component with a limited team size (say, up to 15 people that are in close contact with one another), I believe that it is best to get your code on the mainline as fast as possible. Often, in git terms, the simplest way to do this is simply directly committing and pushing to master. Doing this helps signal conflicting concurrent work early, and it helps avoid double work. It encourages necessary but unforeseen design sessions before the work is done, rather than refactoring sessions afterwards. The only strong downside to super-fast continuous integration that I can see is the chance that you "break the build" (or the tests, or whatever your situation has that needs to be OK for developers to be able to add features). If the team is in close contact, this is typically fixed within minutes ("hey Mike, you broke xyz.cpp" "oh damn, sorry, i'm right on it"), and if it isn't, well, git has cherry-picking features for a reason! You can use the tools to avoid the broken code for a few hours until the guy who broke it is back from the hairdresser. Sure, you can do good CI with feature branches, but people have to be disciplined, and push their feature branch with master very often. Like, multiple times per day. I've never seen that work in practice. This doesn't mean that it can't work in practice, but it does mean that "branch away, buddy!" may be bad general advice. When committing straight to master, the danger is of course that people hold back pushing their commits over the line entirely, which is bad too, but I find that once the horrible, horrible "whoever breaks the build gets pie" rule is replaced by the "whoever pushes more than x changed files/lines at a time gets pie" rule turns that culture around just fine. I'll be the first to admit that this might work less well with e.g. highly distributed teams in different timezones. But that's hardly the most common scenario. Continuous integration is called that for a reason. If you do A-few-times-a-week-integration, then call it that. And in my opinion, you're missing out.
- 14y ago
tocomment 14y ago
Is there any best practice for a large team of 50 developers to work in Git? We have about 20 separate (almost completely separate) projects. We currently have everything under one big SVN directory. I use git for personal stuff so it's always a pain to work in SVN.
- Shish2k 14y ago
  Git is sufficiently good at all workflows that "best practices" depend more on your team and code than any tool-enforced limits. I'm working on moving a dev team from SVN to git myself; the plan that people seem to be happy with is to use git as a drop-in replacement for an iteration or two while people get used to the new tools, and then start introducing people to the more advanced features as and when they seem appropriate, hopefully ending up with a git-flow style workflow.
- groby_b 14y ago
  You can always use git-svn for local sanity :)
  - zwieback 14y ago
    In theory yes, in reality git-svn is driving me insane. I can't wait to move to an all-git solution. Not because I love git but because I can then stop bridging two worlds with git-svn. You can make git-svn work for non-trivial setups but it took me a lot of trial and error, failed merges and git stashes to make it work for me.
    - Shorel 14y ago
      I can feel your pain. Right now I have this workflow: git add filename(s) git stash git svn rebase git svn dcommit git stash pop The worst is failed merges in git svn rebase...
- csense 14y ago
  > Is there any best practice for a large team of 50 developers to work in Git? Think about how the Linux kernel works. A single person at the top who has final say in the final product, a lieutenant responsible for each smaller group working on one subsystem. Insist on keeping your history clean. Good commit messages and comprehensible changesets are necessary to make sure the code is understandable by code review, future maintainers, and when different teams' code needs to interoperate.
doesnt_know 14y ago
There is another good reason to break commits down into small "bricks" (as the author calls them) and that is bisect[1]. Up until very recently I only used a tiny fraction of the git toolbox, but when I was complaining to a friend about how an app I was working on deployed fine on one machine but not on another with the exact same configuration he told me to run bisect. It took me a matter of minutes to zero in on the exact commit that broke the app on that one machine. This would have been something I would have spent hours, possibly days trying to figure out by going over every tiny config detail (it wasn't a config issue). Bisect is a powerful little tool to have in your back pocket when you know something you introduced at some time broke something and you need to find out what. The smaller and more "relevant" you keep your commits, the easier it will be to use. Obviously the opposite is true, if you have these massive commits which change large amounts of different files and/or multiple features, bisect becomes significantly less useful, almost worthless. [1] http://git-scm.com/docs/git-bisect http://git-scm.com/docs/git-bisect
ripperdoc 14y ago
Sorry for going off-topic, but I tried to open this on iPhone and it never finished loading. It's 1.25 MB for one page of 3500 chars of text. Maybe the ratio of polish vs content is a bit too skewed here?
- icebraining 14y ago
  It's strange that coderwall doesn't seem to gzip their CSS nor JS files. It'd cut down their biggest file (~450k) to less than 50k.

113 points by beghbali 14y ago

campo 14y ago

I absolutely agree with this. I recently started working on a small web app as a side project. I was dealing with a lot of elements that were new to me and was constantly pushing the limits of my knowledge and breaking things. I realized I wasn't using the power git provided me with branches. Once I started branching things got quicker and more effective because I could bounce between tasks without affecting my deployment (master branch). In five days of frantic coding using git branching I now have a clean easy deployment of about 750 lines, which I iterated on through four different branches and, probably over 3000 lines of code. It's not perfect, but it's eliminated any apprehension about aggressively changing my application, and made me far more ambitious. I feel great about it.

th0ma5 14y ago
I've had a similar feeling of empowerment, although less structured. With hobby projects where sometimes I realize I was thinking all wrong about a certain solution, I'll just check in what I have and commence the deleting of large blocks. Occasionally I'll go back and find something that maybe was a good idea, but for the most part, having an excuse to part ways with bad ideas has alone been really great.
- campo 14y ago
  That's great, reducing the barrier to entry for new projects allows for more experimentation. More experimentation increases the likelihood you'll stumble upon something you really like! What I meant to say more clearly is that I probably iterated through the creation of that web application so quickly because in five days I committed to git 75 times. In my time at Microsoft I don't know that I would have made 75 commits in a year, and creating new branches was very costly. I got numbers on my git repository by using GitStats: http://gitstats.sourceforge.net/ http://gitstats.sourceforge.net/

rkangel 14y ago

He compares it to SVN, but makes a classic error. In SVN branches and commits are just as cheap as in git (albeit marginally slower to create usually). It's the merges that are expensive. It's there that git wins, with it's better understanding of how content moves around, and the ability of the merge tool to see the history and identify the common ancestor.

_ikke_ 14y ago
Branching in SVN is not cheap. It basically has to copy the entire directory structure into a new subdirectory (branches directory). In git, it just creates one file with a 40 byte hex.
- rkangel 14y ago
  Errr, no - while that's what you see in the directory tree, that's not how it's done internally. SVN has a data model where multiple paths in the repo tree can point to the same underlying file object, so a branch requires no file copies, just updating what the directory tree looks like. Even that is done in a very efficient way. It might not quite be 40 bytes, but it is negligibly small. This technique is in fact extremely similar to how Git works.
- andrewaylett 14y ago
  Server-side, that's cheap -- it doesn't actually copy any data. Client-side, it's also cheap: you `svn switch` to the new branch, which is identical to your old branch, so only minimal housekeeping on disk (just like git).
Peaker 14y ago
Beyond branches being expensive, even commits in svn are expensive. They publish immediately, which requires proof-reading, more testing, before each commit. This means there's an incentive to wait with commits. Even if you do commit to a branch, where publishing is less of a problem, you still might regret a typo in the commit, which cannot (easily) be retroactively fixed whereas in git you can fix your private/unpublished commits as much as you'd like with virtually no drawbacks.

deleted 14y ago

[deleted]

prawks 14y ago

As this is a positive article about git, if the OP reads this, I'd suggest using the word "inexpensive" next time. Cheap often has a negative connotation that something is low-cost at the expense of quality. Just a pet peeve. Git is most certainly not cheaply made.

override 14y ago
Its a title to move eyes on HN, nothing more.
kfinley 14y ago
Yes, but the phrase "x is cheap" often means -- just use it. "x is inexpensive" doesn't have the same connotation. E.g. "memory is cheap"
Cyranix 14y ago
I chose the exact same word "cheap" in a tutorial presentation that I made for new hires and co-op students at my current company. No confusion registered in the audience so far.
_delirium 14y ago
I had sort of the same reaction, but it's one of those language pragmatics that seems heavily dependent on context. "Git is cheap" has the first reading to me with the cheap-crappy-gadget connotation, and I only get the intended meaning on the 2nd wave. But if you said "Git branching is cheap", I read that one as intended immediately.

skrebbel 14y ago

I strongly half-agree here. Commit early, hell yeah! Branch often, umm, no. I feel that the excellent branching features of modern DVCSes have made people lazy and afraid to confront the inherent concurrent nature of working in parallel with people on the same codebase. Sure, if you're a 200 person team, there might be no way around it some decent branching setup. But don't forget: every feature branch means postponing continuous integration. Continuous integration is the core of any productive and effective agile-ish team. Daily standups are nice, backlogs are lovely, but without continuous integration you can't get that design-develop-test cycle short enough to deploy/demo early and often. Therefore, when working on a product or component with a limited team size (say, up to 15 people that are in close contact with one another), I believe that it is best to get your code on the mainline as fast as possible. Often, in git terms, the simplest way to do this is simply directly committing and pushing to master. Doing this helps signal conflicting concurrent work early, and it helps avoid double work. It encourages necessary but unforeseen design sessions before the work is done, rather than refactoring sessions afterwards. The only strong downside to super-fast continuous integration that I can see is the chance that you "break the build" (or the tests, or whatever your situation has that needs to be OK for developers to be able to add features). If the team is in close contact, this is typically fixed within minutes ("hey Mike, you broke xyz.cpp" "oh damn, sorry, i'm right on it"), and if it isn't, well, git has cherry-picking features for a reason! You can use the tools to avoid the broken code for a few hours until the guy who broke it is back from the hairdresser. Sure, you can do good CI with feature branches, but people have to be disciplined, and push their feature branch with master very often. Like, multiple times per day. I've never seen that work in practice. This doesn't mean that it can't work in practice, but it does mean that "branch away, buddy!" may be bad general advice. When committing straight to master, the danger is of course that people hold back pushing their commits over the line entirely, which is bad too, but I find that once the horrible, horrible "whoever breaks the build gets pie" rule is replaced by the "whoever pushes more than x changed files/lines at a time gets pie" rule turns that culture around just fine. I'll be the first to admit that this might work less well with e.g. highly distributed teams in different timezones. But that's hardly the most common scenario. Continuous integration is called that for a reason. If you do A-few-times-a-week-integration, then call it that. And in my opinion, you're missing out.

14y ago

tocomment 14y ago

Is there any best practice for a large team of 50 developers to work in Git? We have about 20 separate (almost completely separate) projects. We currently have everything under one big SVN directory. I use git for personal stuff so it's always a pain to work in SVN.

Shish2k 14y ago
Git is sufficiently good at all workflows that "best practices" depend more on your team and code than any tool-enforced limits. I'm working on moving a dev team from SVN to git myself; the plan that people seem to be happy with is to use git as a drop-in replacement for an iteration or two while people get used to the new tools, and then start introducing people to the more advanced features as and when they seem appropriate, hopefully ending up with a git-flow style workflow.
groby_b 14y ago
You can always use git-svn for local sanity :)
- zwieback 14y ago
  In theory yes, in reality git-svn is driving me insane. I can't wait to move to an all-git solution. Not because I love git but because I can then stop bridging two worlds with git-svn. You can make git-svn work for non-trivial setups but it took me a lot of trial and error, failed merges and git stashes to make it work for me.
  - Shorel 14y ago
    I can feel your pain. Right now I have this workflow: git add filename(s) git stash git svn rebase git svn dcommit git stash pop The worst is failed merges in git svn rebase...
csense 14y ago
> Is there any best practice for a large team of 50 developers to work in Git? Think about how the Linux kernel works. A single person at the top who has final say in the final product, a lieutenant responsible for each smaller group working on one subsystem. Insist on keeping your history clean. Good commit messages and comprehensible changesets are necessary to make sure the code is understandable by code review, future maintainers, and when different teams' code needs to interoperate.

doesnt_know 14y ago

There is another good reason to break commits down into small "bricks" (as the author calls them) and that is bisect[1]. Up until very recently I only used a tiny fraction of the git toolbox, but when I was complaining to a friend about how an app I was working on deployed fine on one machine but not on another with the exact same configuration he told me to run bisect. It took me a matter of minutes to zero in on the exact commit that broke the app on that one machine. This would have been something I would have spent hours, possibly days trying to figure out by going over every tiny config detail (it wasn't a config issue). Bisect is a powerful little tool to have in your back pocket when you know something you introduced at some time broke something and you need to find out what. The smaller and more "relevant" you keep your commits, the easier it will be to use. Obviously the opposite is true, if you have these massive commits which change large amounts of different files and/or multiple features, bisect becomes significantly less useful, almost worthless. [1] http://git-scm.com/docs/git-bisect http://git-scm.com/docs/git-bisect

ripperdoc 14y ago

Sorry for going off-topic, but I tried to open this on iPhone and it never finished loading. It's 1.25 MB for one page of 3500 chars of text. Maybe the ratio of polish vs content is a bit too skewed here?

icebraining 14y ago
It's strange that coderwall doesn't seem to gzip their CSS nor JS files. It'd cut down their biggest file (~450k) to less than 50k.