5 ms·

Why Git is Better Than X

97 points by schacon 18y ago

lowkey 18y ago
I prefer Mercurial (Hg). I'm sure Git is the preferred choice amongst the alpha of alpha geeks, but for small and medium-sized projects, Hg's simple intuitive command structure, and more than adequate speed (2nd only to Git) is a God send. Git just seems overly complex for all but the most sophisticated workflows. I could be wrong, but that has been my experience.
- schacon 18y ago
  I would argue (as I do at the site there) that Git is just as easy to learn and use as Hg, in some cases easier (http://jointheconversation.org/2008/11/24/on-mercurial/ http://jointheconversation.org/2008/11/24/on-mercurial/). The 'Hg is easier' argument tends to be from those who initially tried Git a while ago.
- mindaugas 18y ago
  Actually I started using git just for fun and it was on windows. At first I used just graphical interface gittk. It was very easy and clear. I encourage every git newbie to try gittk. After using gittk "index thing" became a lot clearer. So what I'm trying to say is that Git is not some complex beast with dark powers. P.S. And I'm hardly an alpha geek or even power user.
- sh1mmer 18y ago
  This was my exact argument for Bazaar. After playing with Git 1.6 for a few minutes today all my usual commands work. It took me literally 3.5 minutes to get Git setup using the OSX install package and fixing my .profile to include the new path. I'm very impressed. Now if only Github had a trial membership with a Private repo...
  - bprater 18y ago
    I'm in agreement with Github having a free/trial private repo. It's a huge oversight.
    - mojombo 18y ago
      GitHub is totally free and unrestricted for public code. This should give you plenty of freedom to try out the service without paying. Also, as a promotion for Cyber Monday, new signups today (12/1) can get a paid plan free for one month.
      - tsally 18y ago
        Because of this, I just signed up to try it. I'm going to be honest though: I wouldn't have without a private repository. I like to version control my homework, and obviously it's against school policy to publicly post solutions to homework. If this works out I'll end up paying for a micro plan, but I never would have even given GitHub an opportunity without a private repo. Of course, that's just my opinion. :-) You may not even be targeting students anyway.
  - gcv 18y ago
    I thought github does allow private repositories on the free plan? Maybe something changed, but it used to allow a private repository, but you couldn't share it with anyone.
  - jjburka 18y ago
    http://unfuddle.com/ http://unfuddle.com/ has free private repos and they support git
- orib 18y ago
  I'm reminded of Carl Worth's effort to port the HG guide to Git. It was mostly a search-replace effort, where the concepts were more or less the same, and the commands were similar.
- utx00 18y ago
  i prefer hg too. cheap local branching: there's bookmarks, there's named branches, and there is mq. one of the cool things about mq is that the patch queues can themselves be an hg repo. so if you're using a patch queue like you would the git index, you can 'push' that state somewhere else as way of backup. can one do that with the git-index? (if you rsync your tree, get ready to rsync huge pack files everytime they change .. see below) everything is local: this is the exact same thing on git and hg. hg incoming means check another repo for incoming changesets. ergo it needs to contact that repo which need not be remote. git is fast: we have our source tree in hg and git. ~10k files plus binary stuff. no one notices any difference. on windows, hg is faster. git is small: maybe so. but you have to remember, (and perhaps understand) about git-repack and friends. hg, is like a self-cleaning oven in this regard. staging area: if one needs such a thing, there are mercurial queues. if you dont, it's not in your way. distributed: yes. hg is distributed. that's why it has commands like incoming. any workflow: same thing in both. github: http://www.bitbucket.org/ http://www.bitbucket.org/ easy to learn: git is easier to learn than mercurial? ok, now here's what i don't like about git: storage: it's annoying to have to setup git-repacks jobs for each repo, but that's fine. the real killer for us is that it kills our incremental backup strategy. every time you repack you create a new pack file (in our case huge) and you have to back it up again. in mercurial you can back up the files that changed. bundles: git now has them but they started in mercurial. i'm putting this down because there seems to be this perception that all the cool stuff happens first in git. index: fine after you're a pro, but we have had accidents. learning curve is a bit strict with git. documentation: better in hg. much better actually. git has gone through a lot of interface changes. is cogito still in use? and then they broke renaming at one point. i'm sure these things are fixed, but we've had no such issues in hg thus far. in the end they both rock, but i prefer hg.
  - silentbicycle 18y ago
    > if one needs such a thing, there are mercurial queues. if you dont, it's not in your way. Very true. Mercurial's design puts most of its non-core functionality into extensions (which are easy to ignore if you don't need them), and has a clean setup for adding new extensions. How does git handle that? I haven't looked into the git source lately. And regarding "incoming", the article says that git has a separate command (fetch) for caching server data, i.e. if there are incoming patches, when connections are available. (According to git-fetch(1), fetch looks more like pull without updating/merging locally. Unless I'm misunderstanding things, the comparison to hg's incoming is probably a bit of a stretch.)
justindz 18y ago
I've used svn and git a little and am shopping around for something to use on a current project. I found git harder to use than svn, given that I'm not a power user. I noted that the last item on the page seems to reflect that--git is only easier to learn than perforce, according to the site. Is that really true? I might just be dumb, but I had a harder time with git. Given that I'm in mostly single-user mode, it seems like I might be more productive with svn simply because I wouldn't have to wrestle with it as much to get going. Can anyone recommend a "git for people who can understand and operate svn without hurting themselves?" guide? Or is the value of git significantly lessened in single-user mode?
- schacon 18y ago
  I generally like to try my best to get people to completely forget SVN when learning Git, because I feel that SVN is fundamentally a bad model, BUT - http://git.or.cz/course/svn.html http://git.or.cz/course/svn.html may be what you're looking for. When you want to really learn Git better (and gain hugely in productivity) check out http://gitcasts.com http://gitcasts.com and http://book.git-scm.com http://book.git-scm.com for some Git-specific learning materials.
  - justindz 18y ago
    Thanks to all replies for feedback. I think I will try Git again. Any recommendations on a UI tool (or recommend that I don't use one?). I run Ubuntu and have Vista on my work laptop. If there's a good tool for simplifying adds and commits and what not, I'd like to try that. I think part of my problem might have been that I tried to learn Git using Github, which made a multi-user situation out of a single-user situation and was unnecessarily complex. For my current project, the source is not public so I can't have that problem ;-)
    - schacon 18y ago
      'git gui' is a bit ugly, but it's actually a pretty nice ui in terms of functionality. give that a try, it comes with git. if you want a little primer from a windows perspective, i did a gitcast on installing git on windows and using the 'git gui' here : http://gitcasts.com/posts/git-on-windows http://gitcasts.com/posts/git-on-windows
axod 18y ago
Why I don't care: Because it simply doesn't matter that much IMHO. A startup doesn't succeed or fail based on which RCS it uses, it may fail if it doesn't use any at all, and it may fail if people are wasting a large amount of time doing silly things (Moving directories in cvs). If you're hacking open source projects however, then I'd say Git is most likely the way to go.
- babo 18y ago
  I version control system determines the workflow so it has direct impact of the internals of a company.
  - axod 18y ago
    For a small startup team, say 5 person max, is the workflow using git much different than using svn say?
    - nostrademons 18y ago
      The main advantage I can think of is that git makes it much easier to try out crazy and potentially embarrassing ideas. If you want to do this in svn, you create a branch, which exists on the server, which is visible to everyone else (though I guess many won't have it checked out). And when you commit, you need to be online, unless you've got something like svk. In git, you just create a local branch, try it out, and see if you like the results. If you do, you can have a buddy pull your new branch and see if he likes them, and if everything's good, merge it into master. If you don't, just delete the local branch and nobody's the wiser. Also makes for really quick commits while you're trying things out.
    - llimllib 18y ago
      we're 4 people at a startup using it, and I absolutely love it for the reasons nostrademons mentioned.
    - babo 18y ago
      We used it in a style where 2-3 people teams shared code to develop a feature, a person often worked on different teams at the same time. When a group finished they forwarded they changes to the 'merge master', a weekly shift of lead developers of the company. After a code review the code reached our main repository or landed back for a review. Sometimes weeks of development arrived to the main tree in a safe way with full revision history. This kind of development method was unheard before, the style change improved code quality and reduced conflicts. My favorite story when we worked with a college thousands of kilometers away till the last minute to demonstrate a key feature to a customer at a trade show, exchanging revisions by emails, delivered on a USB stick. That's a real technology start-up way to handle development. I wrote and debug a lot of code to that company but my biggest impact was to introduce mercurial to the team.
newt0311 18y ago
Inaccurate. For example, in the section for "Any Workflow," the author contends that git is better than bzr, hg, svn, and perforce. However, this is completely false. bzr has far better support for the central repository (svn-style workflow) with its linking of repositories and hg and bzr both have excellent support for the models that Git supports. Funny that the site tries to defend against fanboyism while it itself is a poster boy for it.
- wmf 18y ago
  The "Any Workflow" section is a little confusing. The fine print says "[Other SCMs] can do the simple flows I've described above, but they cannot do them with multiple simultaneous local branches." I don't understand this well enough to be convinced, and it's hardly good form to use examples that don't demonstrate your point.
  - schacon 18y ago
    You make a good point, so I have removed the dscm tags from that one. I added this because I feel that the ability to keep full branches in the same repository that you can push and delete easily gives you far greater flexibility than bzr or hg, which you can only get the exact same functionality by having separate repositories that are clones of each other. However, since that's not what I was demonstrating in that section and it's a bit too complicated to amend easily, I've removed it and focused in that section on the advantages over svn and perforce. perhaps later...
    - newt0311 18y ago
      I should point out that hg is perfectly capable of maintaining multiple named branches in the same physical repository. Checkout hg branch. I am not that familiar with bzr but it probably has something similar.
- schacon 18y ago
  I disagree - I feel that the branch model in Git and its support in the distributed models gives Git an advantage over bzr and hg in overall workflow flexibility, including the centralized model. However, wmf below is correct in that I did not defend that properly, so I have amended that section. Furthermore, I have been using Git since the pre 1.0 days several years ago - way before most people were using it, so 'fanboyism', a term that I hate, is obviously not why I use it or why I try to teach it. I feel that it is a legitimately better choice for most people than these other tools and this is my attempt to make those points as simply and as straightforward as possible. If you feel I am technically incorrect on anything, please email me and I _will_ fix it.
vorador 18y ago
Another weekly post about why git's better that anything else. It's just the fourth in four weeks.
halo 18y ago
It's a funny coincidence this turns up when I spent about 30 minutes trying and failing to get Git working with Github earlier. I'm not sure if it was the flaky Windows port or not, but it just wasn't happening.
schacon 18y ago
by the way, as a nice demonstration of some of this git/github greatness, there have been a number of useful changes submitted by users that have been pulled in and deployed now, including the beginnings of a french translation of the site that I've put up at http://fr.whygitisbetterthanx.com http://fr.whygitisbetterthanx.com you can see the network activity here : http://github.com/schacon/whygitisbetter/network http://github.com/schacon/whygitisbetter/network - all of which has happened since I posted this news item 2 hours ago.
apu 18y ago
The whole site would be more convincing if you included a section on reasons why git is worse than X as well. I don't know git well enough to know these, except for one: handling large binary files that change frequently. It would make it seem more honest if you admitted that git wasn't the alpha and the omega when it comes to version control. I think it would also show people that you've carefully thought about this and are not just a 'fanboy'.
- ptman 18y ago
  The counter-arguments are there in the page source as a comment near the end.
  - EliAndrewC 18y ago
    From the comment: THINGS GIT IS STILL NOT GOOD AT * windows (all) * large files (svn)
- asjo 18y ago
  > I don't know git well enough to know these, except for one: handling large binary files that change frequently. For the curious among us: what systems handle this better than git?
  - apu 18y ago
    Subversion is not terrible at this. It stores binary diffs.
    - pmjordan 18y ago
      Maybe they've improved this in recent versions, but I remember this being excruciatingly slow.
  - silentbicycle 18y ago
    This seems fundamentally different from what VCSs are usually designed for, and another category of tool may handle the problem better. Rsync might be a good start.
almost 18y ago
I wish I could use Git on one of my current projects. But I need to work with non-programmers (on OSX in my case) and any command line stuff (or anything more complicated than checkout/add/update/commit) is totally out of the question. Still, I'm sure it won't be long...
- speek 18y ago
  I also work in an environment with people who should not be going near their command line. Well, its not that they shouldn't but they don't want to be forced to learn commands. I'm working on a Git GUI that should be fairly beautiful (I'm a former graphic designer), but there aren't really any good GUIs out there right now. If you do decide to use some sort of VCS, svn has some great GUIs. like Versions (http://www.versionsapp.com/ http://www.versionsapp.com/), Cornerstone (http://www.zennaware.com/cornerstone/ http://www.zennaware.com/cornerstone/) or ZigVersion (http://zigversion.com/ http://zigversion.com/). Versions is nice because it can easily integrate with their hosted subversion stuff called Beanstalk.
  - brunoqc 18y ago
    For Mercurial, there is TortoiseHg: http://tortoisehg.sourceforge.net/ http://tortoisehg.sourceforge.net/
    - silentbicycle 18y ago
      Which works very well on Windows, FWIW.
  - pjhyett 18y ago
    GitX is a very nice GUI for OS X. http://gitx.frim.nl/ http://gitx.frim.nl/
- cstejerean 18y ago
  check out GitX
brunoqc 18y ago
Git seem nice, but as far as I know Github only use ssh. It suck when you are at work or school.
- ptman 18y ago
  How is supporting only SSH bad? SSH is (or really should be) allowed through all firewalls. git:// support would be much harder to get accepted.
cl-user 18y ago
I am more of a bzr and svn user. Both work quite nicely for me. I haven't really used git on a project. I know git performance is much much better than bzr but as thats not a major concern for small/medium projects, could someone who has used both bzr and git give some pointers on what one would be nicer to use than the other in areas other than performance?
- etal 18y ago
  From what I've seen of bzr and git, if you're competent with one, learning the other won't change your life the way a switch from cvs to bzr might. The way git figures out what you've done to a directory tree using sha1 hashes is interesting; incidentally it won't automatically add an empty directory. In bzr, you tell the VCS what you're doing so it can track operations better; git generally doesn't care about anything but the contents of the files in your tree. The staging area and in-place branching in git are pretty cool, but not essential, and I suspect they'll be picked up by bzr and hg in due course. Mark Shuttleworth wrote a series in his blog about what he cares about in version control, and why he picked bzr for Ubuntu and Launchpad, which is an interesting counterpoint to the git lovefest we've been seeing here.

97 points by schacon 18y ago

I prefer Mercurial (Hg). I'm sure Git is the preferred choice amongst the alpha of alpha geeks, but for small and medium-sized projects, Hg's simple intuitive command structure, and more than adequate speed (2nd only to Git) is a God send. Git just seems overly complex for all but the most sophisticated workflows. I could be wrong, but that has been my experience.

schacon 18y ago
I would argue (as I do at the site there) that Git is just as easy to learn and use as Hg, in some cases easier (http://jointheconversation.org/2008/11/24/on-mercurial/ http://jointheconversation.org/2008/11/24/on-mercurial/). The 'Hg is easier' argument tends to be from those who initially tried Git a while ago.
mindaugas 18y ago
Actually I started using git just for fun and it was on windows. At first I used just graphical interface gittk. It was very easy and clear. I encourage every git newbie to try gittk. After using gittk "index thing" became a lot clearer. So what I'm trying to say is that Git is not some complex beast with dark powers. P.S. And I'm hardly an alpha geek or even power user.
sh1mmer 18y ago
This was my exact argument for Bazaar. After playing with Git 1.6 for a few minutes today all my usual commands work. It took me literally 3.5 minutes to get Git setup using the OSX install package and fixing my .profile to include the new path. I'm very impressed. Now if only Github had a trial membership with a Private repo...
- bprater 18y ago
  I'm in agreement with Github having a free/trial private repo. It's a huge oversight.
  - mojombo 18y ago
    GitHub is totally free and unrestricted for public code. This should give you plenty of freedom to try out the service without paying. Also, as a promotion for Cyber Monday, new signups today (12/1) can get a paid plan free for one month.
    - tsally 18y ago
      Because of this, I just signed up to try it. I'm going to be honest though: I wouldn't have without a private repository. I like to version control my homework, and obviously it's against school policy to publicly post solutions to homework. If this works out I'll end up paying for a micro plan, but I never would have even given GitHub an opportunity without a private repo. Of course, that's just my opinion. :-) You may not even be targeting students anyway.
- gcv 18y ago
  I thought github does allow private repositories on the free plan? Maybe something changed, but it used to allow a private repository, but you couldn't share it with anyone.
- jjburka 18y ago
  http://unfuddle.com/ http://unfuddle.com/ has free private repos and they support git
orib 18y ago
I'm reminded of Carl Worth's effort to port the HG guide to Git. It was mostly a search-replace effort, where the concepts were more or less the same, and the commands were similar.
utx00 18y ago
i prefer hg too. cheap local branching: there's bookmarks, there's named branches, and there is mq. one of the cool things about mq is that the patch queues can themselves be an hg repo. so if you're using a patch queue like you would the git index, you can 'push' that state somewhere else as way of backup. can one do that with the git-index? (if you rsync your tree, get ready to rsync huge pack files everytime they change .. see below) everything is local: this is the exact same thing on git and hg. hg incoming means check another repo for incoming changesets. ergo it needs to contact that repo which need not be remote. git is fast: we have our source tree in hg and git. ~10k files plus binary stuff. no one notices any difference. on windows, hg is faster. git is small: maybe so. but you have to remember, (and perhaps understand) about git-repack and friends. hg, is like a self-cleaning oven in this regard. staging area: if one needs such a thing, there are mercurial queues. if you dont, it's not in your way. distributed: yes. hg is distributed. that's why it has commands like incoming. any workflow: same thing in both. github: http://www.bitbucket.org/ http://www.bitbucket.org/ easy to learn: git is easier to learn than mercurial? ok, now here's what i don't like about git: storage: it's annoying to have to setup git-repacks jobs for each repo, but that's fine. the real killer for us is that it kills our incremental backup strategy. every time you repack you create a new pack file (in our case huge) and you have to back it up again. in mercurial you can back up the files that changed. bundles: git now has them but they started in mercurial. i'm putting this down because there seems to be this perception that all the cool stuff happens first in git. index: fine after you're a pro, but we have had accidents. learning curve is a bit strict with git. documentation: better in hg. much better actually. git has gone through a lot of interface changes. is cogito still in use? and then they broke renaming at one point. i'm sure these things are fixed, but we've had no such issues in hg thus far. in the end they both rock, but i prefer hg.
- silentbicycle 18y ago
  > if one needs such a thing, there are mercurial queues. if you dont, it's not in your way. Very true. Mercurial's design puts most of its non-core functionality into extensions (which are easy to ignore if you don't need them), and has a clean setup for adding new extensions. How does git handle that? I haven't looked into the git source lately. And regarding "incoming", the article says that git has a separate command (fetch) for caching server data, i.e. if there are incoming patches, when connections are available. (According to git-fetch(1), fetch looks more like pull without updating/merging locally. Unless I'm misunderstanding things, the comparison to hg's incoming is probably a bit of a stretch.)

justindz 18y ago

I've used svn and git a little and am shopping around for something to use on a current project. I found git harder to use than svn, given that I'm not a power user. I noted that the last item on the page seems to reflect that--git is only easier to learn than perforce, according to the site. Is that really true? I might just be dumb, but I had a harder time with git. Given that I'm in mostly single-user mode, it seems like I might be more productive with svn simply because I wouldn't have to wrestle with it as much to get going. Can anyone recommend a "git for people who can understand and operate svn without hurting themselves?" guide? Or is the value of git significantly lessened in single-user mode?

schacon 18y ago
I generally like to try my best to get people to completely forget SVN when learning Git, because I feel that SVN is fundamentally a bad model, BUT - http://git.or.cz/course/svn.html http://git.or.cz/course/svn.html may be what you're looking for. When you want to really learn Git better (and gain hugely in productivity) check out http://gitcasts.com http://gitcasts.com and http://book.git-scm.com http://book.git-scm.com for some Git-specific learning materials.
- justindz 18y ago
  Thanks to all replies for feedback. I think I will try Git again. Any recommendations on a UI tool (or recommend that I don't use one?). I run Ubuntu and have Vista on my work laptop. If there's a good tool for simplifying adds and commits and what not, I'd like to try that. I think part of my problem might have been that I tried to learn Git using Github, which made a multi-user situation out of a single-user situation and was unnecessarily complex. For my current project, the source is not public so I can't have that problem ;-)
  - schacon 18y ago
    'git gui' is a bit ugly, but it's actually a pretty nice ui in terms of functionality. give that a try, it comes with git. if you want a little primer from a windows perspective, i did a gitcast on installing git on windows and using the 'git gui' here : http://gitcasts.com/posts/git-on-windows http://gitcasts.com/posts/git-on-windows

axod 18y ago

Why I don't care: Because it simply doesn't matter that much IMHO. A startup doesn't succeed or fail based on which RCS it uses, it may fail if it doesn't use any at all, and it may fail if people are wasting a large amount of time doing silly things (Moving directories in cvs). If you're hacking open source projects however, then I'd say Git is most likely the way to go.

babo 18y ago
I version control system determines the workflow so it has direct impact of the internals of a company.
- axod 18y ago
  For a small startup team, say 5 person max, is the workflow using git much different than using svn say?
  - nostrademons 18y ago
    The main advantage I can think of is that git makes it much easier to try out crazy and potentially embarrassing ideas. If you want to do this in svn, you create a branch, which exists on the server, which is visible to everyone else (though I guess many won't have it checked out). And when you commit, you need to be online, unless you've got something like svk. In git, you just create a local branch, try it out, and see if you like the results. If you do, you can have a buddy pull your new branch and see if he likes them, and if everything's good, merge it into master. If you don't, just delete the local branch and nobody's the wiser. Also makes for really quick commits while you're trying things out.
  - llimllib 18y ago
    we're 4 people at a startup using it, and I absolutely love it for the reasons nostrademons mentioned.
  - babo 18y ago
    We used it in a style where 2-3 people teams shared code to develop a feature, a person often worked on different teams at the same time. When a group finished they forwarded they changes to the 'merge master', a weekly shift of lead developers of the company. After a code review the code reached our main repository or landed back for a review. Sometimes weeks of development arrived to the main tree in a safe way with full revision history. This kind of development method was unheard before, the style change improved code quality and reduced conflicts. My favorite story when we worked with a college thousands of kilometers away till the last minute to demonstrate a key feature to a customer at a trade show, exchanging revisions by emails, delivered on a USB stick. That's a real technology start-up way to handle development. I wrote and debug a lot of code to that company but my biggest impact was to introduce mercurial to the team.

newt0311 18y ago

Inaccurate. For example, in the section for "Any Workflow," the author contends that git is better than bzr, hg, svn, and perforce. However, this is completely false. bzr has far better support for the central repository (svn-style workflow) with its linking of repositories and hg and bzr both have excellent support for the models that Git supports. Funny that the site tries to defend against fanboyism while it itself is a poster boy for it.

wmf 18y ago
The "Any Workflow" section is a little confusing. The fine print says "[Other SCMs] can do the simple flows I've described above, but they cannot do them with multiple simultaneous local branches." I don't understand this well enough to be convinced, and it's hardly good form to use examples that don't demonstrate your point.
- schacon 18y ago
  You make a good point, so I have removed the dscm tags from that one. I added this because I feel that the ability to keep full branches in the same repository that you can push and delete easily gives you far greater flexibility than bzr or hg, which you can only get the exact same functionality by having separate repositories that are clones of each other. However, since that's not what I was demonstrating in that section and it's a bit too complicated to amend easily, I've removed it and focused in that section on the advantages over svn and perforce. perhaps later...
  - newt0311 18y ago
    I should point out that hg is perfectly capable of maintaining multiple named branches in the same physical repository. Checkout hg branch. I am not that familiar with bzr but it probably has something similar.
schacon 18y ago
I disagree - I feel that the branch model in Git and its support in the distributed models gives Git an advantage over bzr and hg in overall workflow flexibility, including the centralized model. However, wmf below is correct in that I did not defend that properly, so I have amended that section. Furthermore, I have been using Git since the pre 1.0 days several years ago - way before most people were using it, so 'fanboyism', a term that I hate, is obviously not why I use it or why I try to teach it. I feel that it is a legitimately better choice for most people than these other tools and this is my attempt to make those points as simply and as straightforward as possible. If you feel I am technically incorrect on anything, please email me and I _will_ fix it.

vorador 18y ago

Another weekly post about why git's better that anything else. It's just the fourth in four weeks.

halo 18y ago

It's a funny coincidence this turns up when I spent about 30 minutes trying and failing to get Git working with Github earlier. I'm not sure if it was the flaky Windows port or not, but it just wasn't happening.

schacon 18y ago

by the way, as a nice demonstration of some of this git/github greatness, there have been a number of useful changes submitted by users that have been pulled in and deployed now, including the beginnings of a french translation of the site that I've put up at http://fr.whygitisbetterthanx.com http://fr.whygitisbetterthanx.com you can see the network activity here : http://github.com/schacon/whygitisbetter/network http://github.com/schacon/whygitisbetter/network - all of which has happened since I posted this news item 2 hours ago.

apu 18y ago

The whole site would be more convincing if you included a section on reasons why git is worse than X as well. I don't know git well enough to know these, except for one: handling large binary files that change frequently. It would make it seem more honest if you admitted that git wasn't the alpha and the omega when it comes to version control. I think it would also show people that you've carefully thought about this and are not just a 'fanboy'.

ptman 18y ago
The counter-arguments are there in the page source as a comment near the end.
- EliAndrewC 18y ago
  From the comment: THINGS GIT IS STILL NOT GOOD AT * windows (all) * large files (svn)
asjo 18y ago
> I don't know git well enough to know these, except for one: handling large binary files that change frequently. For the curious among us: what systems handle this better than git?
- apu 18y ago
  Subversion is not terrible at this. It stores binary diffs.
  - pmjordan 18y ago
    Maybe they've improved this in recent versions, but I remember this being excruciatingly slow.
- silentbicycle 18y ago
  This seems fundamentally different from what VCSs are usually designed for, and another category of tool may handle the problem better. Rsync might be a good start.

almost 18y ago

I wish I could use Git on one of my current projects. But I need to work with non-programmers (on OSX in my case) and any command line stuff (or anything more complicated than checkout/add/update/commit) is totally out of the question. Still, I'm sure it won't be long...

speek 18y ago
I also work in an environment with people who should not be going near their command line. Well, its not that they shouldn't but they don't want to be forced to learn commands. I'm working on a Git GUI that should be fairly beautiful (I'm a former graphic designer), but there aren't really any good GUIs out there right now. If you do decide to use some sort of VCS, svn has some great GUIs. like Versions (http://www.versionsapp.com/ http://www.versionsapp.com/), Cornerstone (http://www.zennaware.com/cornerstone/ http://www.zennaware.com/cornerstone/) or ZigVersion (http://zigversion.com/ http://zigversion.com/). Versions is nice because it can easily integrate with their hosted subversion stuff called Beanstalk.
- brunoqc 18y ago
  For Mercurial, there is TortoiseHg: http://tortoisehg.sourceforge.net/ http://tortoisehg.sourceforge.net/
  - silentbicycle 18y ago
    Which works very well on Windows, FWIW.
- pjhyett 18y ago
  GitX is a very nice GUI for OS X. http://gitx.frim.nl/ http://gitx.frim.nl/
cstejerean 18y ago
check out GitX

brunoqc 18y ago

Git seem nice, but as far as I know Github only use ssh. It suck when you are at work or school.

ptman 18y ago
How is supporting only SSH bad? SSH is (or really should be) allowed through all firewalls. git:// support would be much harder to get accepted.

cl-user 18y ago

I am more of a bzr and svn user. Both work quite nicely for me. I haven't really used git on a project. I know git performance is much much better than bzr but as thats not a major concern for small/medium projects, could someone who has used both bzr and git give some pointers on what one would be nicer to use than the other in areas other than performance?

etal 18y ago
From what I've seen of bzr and git, if you're competent with one, learning the other won't change your life the way a switch from cvs to bzr might. The way git figures out what you've done to a directory tree using sha1 hashes is interesting; incidentally it won't automatically add an empty directory. In bzr, you tell the VCS what you're doing so it can track operations better; git generally doesn't care about anything but the contents of the files in your tree. The staging area and in-place branching in git are pretty cool, but not essential, and I suspect they'll be picked up by bzr and hg in due course. Mark Shuttleworth wrote a series in his blog about what he cares about in version control, and why he picked bzr for Ubuntu and Launchpad, which is an interesting counterpoint to the git lovefest we've been seeing here.