9 ms·

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.
        jononor 9y ago
        git reflog has the previous refs, git reset --hard does not remove anything that has been committed. It will however nuke changes that are not committed. Which is exactly what I use it for... But your script sounds like a decent solution if you want also that to be undoable
        chx 9y ago
        A revision control system losing data on a bad ctrl+r is, as I mentioned, a menace.
        weberc2 9y ago
      - alwillis 9y ago
        http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
    - 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?

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.
        jononor 9y ago
        git reflog has the previous refs, git reset --hard does not remove anything that has been committed. It will however nuke changes that are not committed. Which is exactly what I use it for... But your script sounds like a decent solution if you want also that to be undoable
        chx 9y ago
        A revision control system losing data on a bad ctrl+r is, as I mentioned, a menace.
        weberc2 9y ago
    - alwillis 9y ago
      http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
  - 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?