10 ms·

> During the decision about which platform would host our git repositories, we discounted staying on Launchpad itself as its git support was very weak compared

> During the decision about which platform would host our git repositories, we discounted staying on Launchpad itself as its git support was very weak compared to other platforms and the project doesn't appear to be actively developed. How in the heck did Canonical squander such an incredible opportunity to be the de facto standard for Ubuntu/FOSS code hosting by letting Launchpad stale so badly? They freaking built it into their distribution of apt with PPA shortcuts, etc. Unbelievable.

thesmallestcat 9y ago
Are you implying bzr isn't the next big thing??
- weberc2 9y ago
  To be fair git is junk; it's just the standard so everyone has mostly learned it and it gets the job done, but at least Mercurial is better. Probably bzr too. I have probably 5 more years experience with it than Mercurial and I'm still googling for the correct incantation for things that are just infrequent enough for me to commit them to memory. With Mercurial, the command is what you would expect 90% of the time.
  - yock 9y ago
    Considering how many people are incredibly productive with Git, calling it junk might be unfair.
    - krupan 9y ago
      How many people are incredibly productive with git? Or most just kinda productive, as long as an expert isn't too far away from them?
      - jdc0589 9y ago
        git is not complicated 95% of the time. you really only need to learn a handful of commands and read a blog post or two about branching models and you are good to go. is there is some set of problems plaguing git users I've just never run in to?
        bsder 9y ago
        Given that practically every non-beginner git tutorial starts off with "back up your repository", it's quite clear that git gets wedged a lot. Somehow, I rarely see a Mercurial tutorial give that same advice unless you are doing something really experimental.
        swift 9y ago
        If you're writing a non-beginner git tutorial and you feel the need to include advice to "back up your repository" then you haven't done your job. It's incredibly hard to lose data with git - no matter what changes you make, the old commits are still around, because they're immutable. If you lose track of them, there's always "git reflog". I don't want to pounce on you just because you prefer Mercurial to git, so this isn't really directed at you, but in general this line of argument is always a bit frustrating to me. I've never lost data with git, but I've lost data with Mercurial several times because of the terrible UI of "hg resolve", which throws away your changes without warning unless you remember to type "hg resolve -m". None of git's questionable UI decisions (and there are many) has caused me remotely as much trouble as "hg resolve".
        chx 9y ago
        It's way too easy to lose work with git. The easy availability of git reset --hard is a menace. I am using this https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 shell script to make it not lose data. And it's a disgrace I need to do this. Disk space is free (within measurement error, especially for 99.99% of codebases) so just put that thing somewhere and if necessary I can use date and pickaxe to dig it up.
      - chx 9y ago
        You can become that expert too by reading this tutorial. https://www.sbf5.com/~cduan/technical/git/ https://www.sbf5.com/~cduan/technical/git/ It doesn't teach you commands at first because: > you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.
        chii 9y ago
        you shouldn't _need_ to understand how git internally works to use it (and if you did, then it confirms that git isn't good). You should understand the abstract model of DVCS that git presents (just like you'd need to understand the abstract model of a car to drive it).
        db48x 9y ago
        Understanding the abstract model is exactly what people mean when they say this. It just happens that Git's implementation is incredibly close to the abstract model. This was particularly true in the beginning, before regiments such as pack files were introduced. Those regiments complicate the implementation somewhat, but haven't changed the abstract model at all.
        db48x 9y ago
        err, s/regiments/refinements/g. Thank you, autocomplete.
        chii 9y ago
        > Git's implementation is incredibly close to the abstract model which is exactly why a lot of people claim that git is shit. The fact that it "won" makes those people more angry.
        qb45 9y ago
        Oh well. OTOH, I'm a kind of guy who just must take everything apart before using it and I like the brutal simplicity of git ;) The naming of commands could be better, though.
    - weberc2 9y ago
      Yeah, it was hyperbole. Git does the job.
    - alkonaut 9y ago
      People are productive in C too. C (like git) It's very good at what it was intended for, but everyone and their mother using git on the command line for VCS now is as if everyone had just used C to do every website, game, app etc since 1980. Git, like C, is a solid core but by now we should have better abstractions to help people be even more productive.
  - catdog 9y ago
    Why should git be junk? Sure its commands may not be the most intuitive but apart from that it's fast, flexible and works well. Git has won, get over it.
    - weberc2 9y ago
      The time I spend waiting for my dvcs is trivial compared to the time I spend interacting with it. I use git, and it gets the job done, but I'll still lament that fate chose git over any of the superior alternatives.
  - enobrev 9y ago
    I remember when dvcs really started taking off, I went with bzr because of the simplicity of the UI. I was also on Windows at the time (wow, that was a while ago!), and git didn't have native windows support back then while bzr did. I still much prefer bzr's UI from what I remember of it. It was simple, consistent, and perfectly fine with the occasional typo. But suddenly "everything" was on git; github was a rocket; bzr just felt slower and slower as my repos grew; launchpad was incredibly confusing; I'd been using git/github for outside projects and finally tried git for one of my own, and then started getting confused between the UIs. I picked the one that had the better trajectory. Also, we (the startup I was with) were starting to hire people and using git was easier than forcing the new people to learn bzr. Mercurial looks great, and always has. I just never really had an incentive to switch to it. Edit: Sorry, got lost in my own story. I agree with the siblings here. "junk" is rather strong for something that's so universally used. I don't love git, but it definitely won my support.
    - weberc2 9y ago
      I liked your story, and "junk" was definitely hyperbole. Git gets the job done.
  - Ace17 9y ago
    Long time user of both bazaar and git here. > To be fair git is junk; git's UI could certainly benefit from some simplification ; this doesn't make git junk, especially considering that it's incredibly fast and reliable. > it's just the standard so everyone has mostly learned it and it gets the job done, but at least Mercurial is better. Probably bzr too. Bazaar and git actually have lots in common, they both have the advantages of DVCS (which seem to be often confused with "the advantages of git") (like, say, "rename"?) Here are the main differences I noticed: Bazaar is definitely slower, but you need an big-open-source-sized repo before noticing the difference. Bazaar doesn't have "rebase" by default, but you can install it as a plugin and it works. Bazaar has an optional "automatic push after each commit", which encourages linear history, and which I find to be more appropriate 90% of the time in a small experimented team (small and frequent commits instead of feature-branches). Bazaar's UI uses revision numbers instead of commit hashes, this makes lots of things easier, like knowing which of two commits came first, telling a commit number to your coworkers, or bisecting without requiring the support from the VCS ( git-bisect ). Bazaars allows remotely fetching one single revision from a repo, without requiring to download the whole history. You can't do this with git. The best I found was to loop "git fetch --depth N" with an increasing value of N until the "git checkout <commit_number>" succeeds. This is a pain, especially when working with submodules. Bazaar doesn't have an index (aka "staging area"), and by default, "bzr commit" will commit all the local modifications. Considering that partial commits are dangerous (test suites generally don't track what's in the index, creating a mismatch between "what was tested" and "what's being pushed"), this is a welcomed simplification (of course, you can "git stash/bzr shelve" if needed). Bazaar doesn't make a difference between a branch, a repo, and a working copy. All of these are repositories (potentially sharing ancestors) accessible through an URL. So there's no need for "remotes", you directly push/pull to/from an URL (no, you don't have to re-specify it each time). I hope no git user was harmed during the reading of this post :-)
    - mushishi 9y ago
      If by "test suites" you mean automatic testing, then I probably don't agree. The flow goes like this for me: - Make small amount of new code backed by tests in a feature branch - Run some tests locally (not all) - Push to the feature branch - CI will run all the tests - If a test fails, I get a notification about it in my IDE and can fix it immediately I personally enjoy having staging area (and IDE supported local stash) that help me keep small amount of difference to the origin for development purposes.
  - sspiff 9y ago
    I agree that the CLI of Mercurial is much more thought out than that of git, but calling git crap is unreasonable.
    - weberc2 9y ago
      Fair point. I was exaggerating.
  - akvadrako 9y ago
    Git did have one big advantage over Hg at the time, which was speed; a relevant criteria for Linux. I do agree ending up with git was unfortunate. After trying all the popular choices, Monotone was what I would have picked. Fast, secure, portable and simple. But Linus didn't like it because it supported cherry-picking, which apparently is an anti-feature for a VCS :)
    - mkesper 9y ago
      This is bullshit. git had to support cherry-picking from day one and monotone was extremely slow. Some background: https://lwn.net/Articles/574075/ https://lwn.net/Articles/574075/
      - akvadrako 9y ago
        Your link has nothing to do with your argument. Monotone was slow back when git didn't exist, but later versions greatly improved that. Also, it's clear Linus didn't like cherry-picking, but other people convinced him to add it to git.
- s73ver 9y ago
  What compelling reason does bzr offer average teams to use it over git?
catdog 9y ago
Apparently they started this thing right at the time where distributed version control systems started to take off, years before github (more or less at the same time git appeared). They were very early and clearly missed a big opportunity there. Apart from realizing too late that people jumped onto git instead of their bazaar the PPA thing also is limited to Ubuntu, no support for other distributions, not even Debian. If they had made it a more universal solution back in the day this surely would have been a compelling argument for a lot of projects to move there. Another pain point is the UI, maybe not as bad as sourceforge but still cluttered and confusing.
- teraflop 9y ago
  Yeah, among many other reasons, this is an example of Canonical's general proprietary attitude coming back to bite them. For instance, see this FAQ answer[1]: it comes right out and says that they have no interest in making it easy for anyone else to run instances of Launchpad, and that they only open-sourced it so that outside users could contribute improvements to Canonical's hosted service. I'm not surprised that nobody wants to work on a project like that unless they're getting paid to do so. [1]: https://answers.launchpad.net/launchpad/+faq/920 https://answers.launchpad.net/launchpad/+faq/920
rectang 9y ago
Code hosting services are never forever. Sourceforge aged and fell from grace. Google Code shut down. Github's time will pass as well.
- deleted 9y ago
  [deleted]
- chii 9y ago
  i think github will have learnt from sourceforge's mistakes though.
  - stephenr 9y ago
    While that's better than not learning from the mistakes of the past, how can you possibly believe that there are no new mistakes to be made, or opportunities to miss out on. GitHub's major selling point is mindshare/popularity, and git by default makes moving to another git hosting service relatively trivial. Yes, there are issues to transfer, but it's nowhere near as difficult as in the days of SVN, where you'd need to have shell access to dump the repo, or hope it was a modern enough svn version to support remote dumps (and that they didn't time out).
- skinnymuch 9y ago
  Maybe. But that was a common thing to say about search engines before the mid to late 00s, about Facebook related to social networks just a few years ago..and to this day, and about messaging perhaps to this day as well while that has pretty much stabilized too. I'm not saying I'd bet money on Github being a front runner in say 5 years, but it isn't that unlikely for them to still be the site in 5 or 10 years.
- taeric 9y ago
  Sourceforge fell from grace due to ads. Google Code just went the way of many of Google's side projects. (Also, I don't recall it being that heavily used. Just my memory?) I'll confess that I feel that github will eventually wane. But, I can't say why I think that right off. When they run out of money? Start failing at the hosting portion of what they do in favor of other things?
SwellJoe 9y ago
They bet quite heavily on Launchpad and related infrastructure, but a few things happened on the way to the opera, and here we are. They hired bzr developers, including some really bright folks (Robert Collins, who I knew from the Squid project, was one of them, but there were others). Had git not exploded in popularity and pretty much decimated the competing DVCS projects (or just grew so much faster that the end result was the same...tiny percentage user base for everything other than git), the landscape may have looked different. It took several hosting services a while to figure out that git was all that mattered. Hell, even Microsoft and Google gave up on hosting code. If they can't do it, how can we expect Ubuntu to get it right enough fast enough? Github both got lucky and made some very good decisions very early. Survival bias looks like anybody could have done it...but, a lot of stuff had to fall into place, and it wasn't obvious to everyone what it ought to look like or how to get there.
- hasenj 9y ago
  Google and Microsoft obviously can do it; they just don't want to spend resources on a public service when there are many other alternatives.
  - falsedan 9y ago
    Pretty sure Google can't do user-facing tools that have a greater support burden than "FYI type your query into the box" (and also don't generate revenue) To be clear: the resources+alternatives aren't a problem, it's big G's inability to convert them into a revenue stream with light support/maintenance costs.

thesmallestcat 9y ago

Are you implying bzr isn't the next big thing??

weberc2 9y ago
To be fair git is junk; it's just the standard so everyone has mostly learned it and it gets the job done, but at least Mercurial is better. Probably bzr too. I have probably 5 more years experience with it than Mercurial and I'm still googling for the correct incantation for things that are just infrequent enough for me to commit them to memory. With Mercurial, the command is what you would expect 90% of the time.
- yock 9y ago
  Considering how many people are incredibly productive with Git, calling it junk might be unfair.
  - krupan 9y ago
    How many people are incredibly productive with git? Or most just kinda productive, as long as an expert isn't too far away from them?
    - jdc0589 9y ago
      git is not complicated 95% of the time. you really only need to learn a handful of commands and read a blog post or two about branching models and you are good to go. is there is some set of problems plaguing git users I've just never run in to?
      - bsder 9y ago
        Given that practically every non-beginner git tutorial starts off with "back up your repository", it's quite clear that git gets wedged a lot. Somehow, I rarely see a Mercurial tutorial give that same advice unless you are doing something really experimental.
        swift 9y ago
        If you're writing a non-beginner git tutorial and you feel the need to include advice to "back up your repository" then you haven't done your job. It's incredibly hard to lose data with git - no matter what changes you make, the old commits are still around, because they're immutable. If you lose track of them, there's always "git reflog". I don't want to pounce on you just because you prefer Mercurial to git, so this isn't really directed at you, but in general this line of argument is always a bit frustrating to me. I've never lost data with git, but I've lost data with Mercurial several times because of the terrible UI of "hg resolve", which throws away your changes without warning unless you remember to type "hg resolve -m". None of git's questionable UI decisions (and there are many) has caused me remotely as much trouble as "hg resolve".
        chx 9y ago
        It's way too easy to lose work with git. The easy availability of git reset --hard is a menace. I am using this https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 shell script to make it not lose data. And it's a disgrace I need to do this. Disk space is free (within measurement error, especially for 99.99% of codebases) so just put that thing somewhere and if necessary I can use date and pickaxe to dig it up.
    - chx 9y ago
      You can become that expert too by reading this tutorial. https://www.sbf5.com/~cduan/technical/git/ https://www.sbf5.com/~cduan/technical/git/ It doesn't teach you commands at first because: > you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.
      - chii 9y ago
        you shouldn't _need_ to understand how git internally works to use it (and if you did, then it confirms that git isn't good). You should understand the abstract model of DVCS that git presents (just like you'd need to understand the abstract model of a car to drive it).
        db48x 9y ago
        Understanding the abstract model is exactly what people mean when they say this. It just happens that Git's implementation is incredibly close to the abstract model. This was particularly true in the beginning, before regiments such as pack files were introduced. Those regiments complicate the implementation somewhat, but haven't changed the abstract model at all.
        db48x 9y ago
        err, s/regiments/refinements/g. Thank you, autocomplete.
        chii 9y ago
        > Git's implementation is incredibly close to the abstract model which is exactly why a lot of people claim that git is shit. The fact that it "won" makes those people more angry.
        qb45 9y ago
        Oh well. OTOH, I'm a kind of guy who just must take everything apart before using it and I like the brutal simplicity of git ;) The naming of commands could be better, though.
  - weberc2 9y ago
    Yeah, it was hyperbole. Git does the job.
  - alkonaut 9y ago
    People are productive in C too. C (like git) It's very good at what it was intended for, but everyone and their mother using git on the command line for VCS now is as if everyone had just used C to do every website, game, app etc since 1980. Git, like C, is a solid core but by now we should have better abstractions to help people be even more productive.
- catdog 9y ago
  Why should git be junk? Sure its commands may not be the most intuitive but apart from that it's fast, flexible and works well. Git has won, get over it.
  - weberc2 9y ago
    The time I spend waiting for my dvcs is trivial compared to the time I spend interacting with it. I use git, and it gets the job done, but I'll still lament that fate chose git over any of the superior alternatives.
- enobrev 9y ago
  I remember when dvcs really started taking off, I went with bzr because of the simplicity of the UI. I was also on Windows at the time (wow, that was a while ago!), and git didn't have native windows support back then while bzr did. I still much prefer bzr's UI from what I remember of it. It was simple, consistent, and perfectly fine with the occasional typo. But suddenly "everything" was on git; github was a rocket; bzr just felt slower and slower as my repos grew; launchpad was incredibly confusing; I'd been using git/github for outside projects and finally tried git for one of my own, and then started getting confused between the UIs. I picked the one that had the better trajectory. Also, we (the startup I was with) were starting to hire people and using git was easier than forcing the new people to learn bzr. Mercurial looks great, and always has. I just never really had an incentive to switch to it. Edit: Sorry, got lost in my own story. I agree with the siblings here. "junk" is rather strong for something that's so universally used. I don't love git, but it definitely won my support.
  - weberc2 9y ago
    I liked your story, and "junk" was definitely hyperbole. Git gets the job done.
- Ace17 9y ago
  Long time user of both bazaar and git here. > To be fair git is junk; git's UI could certainly benefit from some simplification ; this doesn't make git junk, especially considering that it's incredibly fast and reliable. > it's just the standard so everyone has mostly learned it and it gets the job done, but at least Mercurial is better. Probably bzr too. Bazaar and git actually have lots in common, they both have the advantages of DVCS (which seem to be often confused with "the advantages of git") (like, say, "rename"?) Here are the main differences I noticed: Bazaar is definitely slower, but you need an big-open-source-sized repo before noticing the difference. Bazaar doesn't have "rebase" by default, but you can install it as a plugin and it works. Bazaar has an optional "automatic push after each commit", which encourages linear history, and which I find to be more appropriate 90% of the time in a small experimented team (small and frequent commits instead of feature-branches). Bazaar's UI uses revision numbers instead of commit hashes, this makes lots of things easier, like knowing which of two commits came first, telling a commit number to your coworkers, or bisecting without requiring the support from the VCS ( git-bisect ). Bazaars allows remotely fetching one single revision from a repo, without requiring to download the whole history. You can't do this with git. The best I found was to loop "git fetch --depth N" with an increasing value of N until the "git checkout <commit_number>" succeeds. This is a pain, especially when working with submodules. Bazaar doesn't have an index (aka "staging area"), and by default, "bzr commit" will commit all the local modifications. Considering that partial commits are dangerous (test suites generally don't track what's in the index, creating a mismatch between "what was tested" and "what's being pushed"), this is a welcomed simplification (of course, you can "git stash/bzr shelve" if needed). Bazaar doesn't make a difference between a branch, a repo, and a working copy. All of these are repositories (potentially sharing ancestors) accessible through an URL. So there's no need for "remotes", you directly push/pull to/from an URL (no, you don't have to re-specify it each time). I hope no git user was harmed during the reading of this post :-)
  - mushishi 9y ago
    If by "test suites" you mean automatic testing, then I probably don't agree. The flow goes like this for me: - Make small amount of new code backed by tests in a feature branch - Run some tests locally (not all) - Push to the feature branch - CI will run all the tests - If a test fails, I get a notification about it in my IDE and can fix it immediately I personally enjoy having staging area (and IDE supported local stash) that help me keep small amount of difference to the origin for development purposes.
- sspiff 9y ago
  I agree that the CLI of Mercurial is much more thought out than that of git, but calling git crap is unreasonable.
  - weberc2 9y ago
    Fair point. I was exaggerating.
- akvadrako 9y ago
  Git did have one big advantage over Hg at the time, which was speed; a relevant criteria for Linux. I do agree ending up with git was unfortunate. After trying all the popular choices, Monotone was what I would have picked. Fast, secure, portable and simple. But Linus didn't like it because it supported cherry-picking, which apparently is an anti-feature for a VCS :)
  - mkesper 9y ago
    This is bullshit. git had to support cherry-picking from day one and monotone was extremely slow. Some background: https://lwn.net/Articles/574075/ https://lwn.net/Articles/574075/
    - akvadrako 9y ago
      Your link has nothing to do with your argument. Monotone was slow back when git didn't exist, but later versions greatly improved that. Also, it's clear Linus didn't like cherry-picking, but other people convinced him to add it to git.
s73ver 9y ago
What compelling reason does bzr offer average teams to use it over git?

catdog 9y ago

Apparently they started this thing right at the time where distributed version control systems started to take off, years before github (more or less at the same time git appeared). They were very early and clearly missed a big opportunity there. Apart from realizing too late that people jumped onto git instead of their bazaar the PPA thing also is limited to Ubuntu, no support for other distributions, not even Debian. If they had made it a more universal solution back in the day this surely would have been a compelling argument for a lot of projects to move there. Another pain point is the UI, maybe not as bad as sourceforge but still cluttered and confusing.

teraflop 9y ago
Yeah, among many other reasons, this is an example of Canonical's general proprietary attitude coming back to bite them. For instance, see this FAQ answer[1]: it comes right out and says that they have no interest in making it easy for anyone else to run instances of Launchpad, and that they only open-sourced it so that outside users could contribute improvements to Canonical's hosted service. I'm not surprised that nobody wants to work on a project like that unless they're getting paid to do so. [1]: https://answers.launchpad.net/launchpad/+faq/920 https://answers.launchpad.net/launchpad/+faq/920

rectang 9y ago

Code hosting services are never forever. Sourceforge aged and fell from grace. Google Code shut down. Github's time will pass as well.

deleted 9y ago
[deleted]
chii 9y ago
i think github will have learnt from sourceforge's mistakes though.
- stephenr 9y ago
  While that's better than not learning from the mistakes of the past, how can you possibly believe that there are no new mistakes to be made, or opportunities to miss out on. GitHub's major selling point is mindshare/popularity, and git by default makes moving to another git hosting service relatively trivial. Yes, there are issues to transfer, but it's nowhere near as difficult as in the days of SVN, where you'd need to have shell access to dump the repo, or hope it was a modern enough svn version to support remote dumps (and that they didn't time out).
skinnymuch 9y ago
Maybe. But that was a common thing to say about search engines before the mid to late 00s, about Facebook related to social networks just a few years ago..and to this day, and about messaging perhaps to this day as well while that has pretty much stabilized too. I'm not saying I'd bet money on Github being a front runner in say 5 years, but it isn't that unlikely for them to still be the site in 5 or 10 years.
taeric 9y ago
Sourceforge fell from grace due to ads. Google Code just went the way of many of Google's side projects. (Also, I don't recall it being that heavily used. Just my memory?) I'll confess that I feel that github will eventually wane. But, I can't say why I think that right off. When they run out of money? Start failing at the hosting portion of what they do in favor of other things?

SwellJoe 9y ago

They bet quite heavily on Launchpad and related infrastructure, but a few things happened on the way to the opera, and here we are. They hired bzr developers, including some really bright folks (Robert Collins, who I knew from the Squid project, was one of them, but there were others). Had git not exploded in popularity and pretty much decimated the competing DVCS projects (or just grew so much faster that the end result was the same...tiny percentage user base for everything other than git), the landscape may have looked different. It took several hosting services a while to figure out that git was all that mattered. Hell, even Microsoft and Google gave up on hosting code. If they can't do it, how can we expect Ubuntu to get it right enough fast enough? Github both got lucky and made some very good decisions very early. Survival bias looks like anybody could have done it...but, a lot of stuff had to fall into place, and it wasn't obvious to everyone what it ought to look like or how to get there.

hasenj 9y ago
Google and Microsoft obviously can do it; they just don't want to spend resources on a public service when there are many other alternatives.
- falsedan 9y ago
  Pretty sure Google can't do user-facing tools that have a greater support burden than "FYI type your query into the box" (and also don't generate revenue) To be clear: the resources+alternatives aren't a problem, it's big G's inability to convert them into a revenue stream with light support/maintenance costs.