8 ms·

Quoting myself from yesterday: https://news.ycombinator.com/threads?id=miohtama https://news.ycombinator.com/threads?id=miohtama "Git is what a version contro

• ryl00 7y ago
  > However they were slower - but not much I don't think we should underestimate how much performance differences can color opinions here, especially for something like CLI tools that are used all the time. Little cuts add up. At work I use both git and bazaar, and bazaar's sluggishness makes me tend to avoid it when possible. I recall Mercurial recently announced an attempt to rewrite core(?) parts in Rust, because python was just not performant enough.
  • ambicapter 7y ago
    At my current place of employment, I don't find git to be super performant. We do have an ugly monolith of a repo though.
    • wstuartcl 7y ago
      Unless you are hitting large binary checkins and not utilizing LFS I can't imagine a scenario where another current RCS would perform better.
      • tsimionescu 7y ago
        Unless you mean another DVCS, P4 can run circles around git on large repos (mostly on account of not conceptually trying to copy the entire state of the entire repo at every commit).
        • Arelius 7y ago
          Run a reconcile offline changes on an actually large repo and come back and tell me that again. ;)
      • masklinn 7y ago
        "Large binary checkins" is not the actual issue. Git degrades as repository size increases. Large binary checkins make it much easier / faster to reach this situation, but you can also reach it just fine with regular text-based repository if they're big and have a significant history (long-lived and many contributors).
  • fragmede 7y ago
    The speed of branching in git, compared to subversion, was a huge part of convincing me to move. Not an entirely "fair" comparison given that subversion is a centralized VCS, but speed is very important.
    • rumanator 7y ago
      Isn't subversion's take on branching, as well as tagging, actually copying/duplicating whole directory trees?
      • adrianmsmith 7y ago
        This is the interface you're presented with, but it's actually a "cheap copy" underneath. So if you write "svn cp https://svn.myserver.com/trunk https://svn.myserver.com/trunk https://svn.myserver.com/branches/foo" https://svn.myserver.com/branches/foo" that takes about 1-2 seconds in my experience (no matter how many files, how long the history, or how many binary files you have, etc.).
  • miohtama 7y ago
    Related to this here is some discussion from Facebook, Microsoft, and why Facebook is using Mercurial over Git: https://news.ycombinator.com/item?id=16565299 https://news.ycombinator.com/item?id=16565299
  • ken 7y ago
    Likewise, Git has been steadily improving on the user interface front for years. It's much better than 1.0 was, but it's still not the easiest DVCS to learn. In my experience, saving a little on runtime doesn't make up for having to crack open the manual even once. UI is a big cut. From an implementation POV, it's also generally easier to rewrite core parts in a lower-level language, than it is to redesign a (scriptable, deployed) UI.
    • beagle3 7y ago
      > From an implementation POV, it's also generally easier to rewrite core parts in a lower-level language, than it is to redesign a (scriptable, deployed) UI. But only if the data structure is simple and works well for the problem domain. Bazaar (a DVCS from Ubuntu; I mean bzr, not baz) had a much simpler and consistent UI, but it had several revisions to the data structures, each one quite painful, and it was slow; they were planning the rewrite to a faster language but never got to it. (Mercurial also used Python and wasn't remotely as slow as bzr - the data structures matter more than the language).
    • baot 7y ago
      >In my experience, saving a little on runtime doesn't make up for having to crack open the manual even once. Please don't ask me to give up features so you don't have to read the documentation. It is the most basic step of being a good citizen in a software ecosystem.
    • Arelius 7y ago
      > In my experience, saving a little on runtime doesn't make up for having to crack open the manual even once. UI is a big cut. Maybe, but I used to work in a multi-GB hg repo, and I would have given up any amount of manual cracking to get the git speed up. Generally you only open the manual a few times, but you can sync many times a day. I'd give a lot to get big speeds up in daily operations for something I use professionally.
• asimpletune 7y ago
  What don’t you like about git?
  • tantalor 7y ago
    Using it, probably.
  • miohtama 7y ago
    7000 votes on https://stackoverflow.com/questions/4114095/how-do-i-revert-a-git-repository-to-a-previous-commit https://stackoverflow.com/questions/4114095/how-do-i-revert-... If one cannot figure one of the most common use case of a version control system without Googling a StackOverflow answer then we have a problem somewhere.
    • snowwrestler 7y ago
      Reading the answers to that Stack Overflow question provides great insight into why git is so successful. "One of the most common use case" is actually several closely related use cases, and git has one-line commands to cleanly handle all of them. I will say from experience that it's not hard to use git productively with a bit of self-study and only a few of the most common commands. You still have to understand what those commands actually do, though.
    • yrro 7y ago
      To be fair, 'revert' is too vague a term, and the very first sentence of the chosen answer asks what the asker meant. I think the answer is quite clear and concise once the question is clear.
    • NoodleIncident 7y ago
      This person didn't know (or at least didn't know how to say) which of the several "most common use cases" they wanted to actually accomplish. I think most of the value of this question comes from the distinctions the top voted answers make between "temporarily navigate to", "delete local progress", "publish the reverse of the published changes"; all three of these are very common operations. The actual commands git uses to accomplish these aren't important, and this question should be popular in any distributed version control system. It doesn't matter how much sense the names of your commands make, someone starting out won't know that these three things can even be accomplished.
• brobdingnagians 7y ago
  Fossil. It's very fast, works well on low bandwidth connections, much cleaner interface, highly customizable, very easy to setup and self host. And the repo is stored in a SQLite database, so it is very easy to backup and explore w/ SQL. It's a shame it isn't more widely used.
  • tangent128 7y ago
    I love much about Fossil and used it a lot several years ago, but my workflow have mental model have since come to rely heavily on interactive rebase, a philosophy that Fossil abhors.
    • SQLite 7y ago
      Indeed. Explanation at https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md
• braindeath 7y ago
  > Back in a day we had Subversion, Mercurial, Bazaar, some others. I don’t agree bazaar was a UX panacea over git, and it was not just “not by much” slower. Subversion was a piece of shit full stop (especially if you had the misfortune of using the original bdb impl), bested in this regard only by VSS. I think slower “not by much” is the understatement of the century for a repo of any substantial size for all but mercurial on your list. You don’t even mention perforce, leading me to think most of your experience is skewed by the niche of small open source projects. Mercurial was a contender... great windows support too. I think it was less kernel that killed it and more github.
  • WorldMaker 7y ago
    Bitbucket started about the same exact time as GitHub. It's not necessarily a given that Mercurial lost because of GitHub. I think it was perceived performance that led git to besting Mercurial, which the Linux Kernel team certainly contributed to that drama, including the usual "C is faster than Python" one-upmanship, this especially funny because it was despite most of git at the time being a duct taped assortment of nearly as much bash, perl, awk, sed scripts as C code.
• miki123211 7y ago
  I don't understand why people aren't using Fossil[1]. It's still simple, while maintaining a consistent and sensible user interface. It might not be as flexible, but the repos are just sqlite databases, and Sqlite can be called from almost any language, so there's huge potential for custom tools that solve a specific use-case etc. It's main advantage, though, is that it's about much more than just code. Issues (called tickets), Wikis or even Forums can be a part of your repo. That means there's absolutely no vendor lock in. In fact, you can host your repos by just SCPing a repo file to a public server. You can also collaborate on issues offline etc. It's written by the Sqlite guy, so it's highly reliable and well documented, upto the technical details like file formats etc. It's designed so that repos can last for hundreds of years. The C code is also of very high quality.
  • acuozzo 7y ago
    > I don't understand why people aren't using Fossil For the same reason that BD won over HD-DVD: «Greater capacity tends to be preferred to better UX», except in this case it's performance rather than capacity.
• WorldMaker 7y ago
  > Will we see another DVCS ever again? I hope yes. As just the first example off the top of my head, Pijul [1] is "new" compared to the others you listed. There will likely always be folks exploring alternatives. > Now all software developers with less than 5 years of experience are using Google and GitHub as the user interface for Git. Git's cognitive burden is terrible and can be solved. However Git authors themselves are not priorising this. I have the opposite impression, that the Git Team is finally getting serious about the UX, whether its just all the fresh blood (thanks at least partly to Microsoft moving some of their UX teams off of proprietary VCSes to converge on git), or that Git's internals are now stable enough that the Git team feels it is time to focus on UX (as that was always a stated goal that they'd return to UX when all the important stuff was done). Clear example: The biggest and first announcement in the most recent Git release notes was about the split of `git checkout` into `git switch` and `git restore`. That's a huge UX change intended to make a lot of people's lives easier, simplifying what is often people's most common, but most sometimes most conceptually confusing git command given the variety of things that `git checkout` does. The Git UX is better today than it was when it first "beat" Mercurial in the marketplace, and there seems to be at least some interests among git contributors to make it better. [1] https://pijul.org/ https://pijul.org/
• greggman2 7y ago
  I'm going to say this again and take the downvotes but it's comments like this that generally come from people who don't get git. git is not the same as those other pieces of software mentioned. git's default workflow encourages lots of parallel work and making tons of branches (which because of bad naming are confusing because git branches are not what other software calls branches) . it's a fundamental difference and has increased my productivity and changed my work style for the positive in ways what would never have happened with CVS, svn, p4, hg, etc... all of which I used in the past for large projects. If you're using git and your mental model is still one of those other systems you're doing it wrong or rather you still don't get it and are missing out. I'm not suggesting the UX couldn't be better but when you finally get it you'll at least understand what it's doing and why the UXs for those other systems are not sufficient.
• beagle3 7y ago
  > However they were slower - but not much CVS was much much much slower; multiple branch handling was horrible until ~2004 (and even on a single branch you did not have atomic commits). Also, no disconnected operation. SVN was only a little slower than git, but didn't have disconnected operation, and horrible merge handling until even later (2007 or 2008, I think) Bazaar 2 was, at the time, while comparable in features, dead slow compared to git. But it also sufferend from bazaar1 (branched from arch=tla) being incompatible with bazaar2 and an overall confusing situation. Mercurial and Git were a toss-up. Git was faster and had Linus aura, Mercurial had better UI and Windows support. But all the early adopters were on Unix, and thus the Linus aura played a much bigger part than the Win32 support. Github became externally well funded after the war was over. But it was self well funded, because git was more popular (in part because github made it so ...) Really, I think the crux of the matter is that Git's underlying data model is really simple, and the early adopters were fine with UX ... mostly because those adopters were Perl and C people. So the UX was not a factor, but speed and Linus aura were.
  • miohtama 7y ago
    A very good insight, sir! Your memory serves better than mine. However I believe in long run Hg caught up in the speed and Bazaar was getting a lot of better as well. SVN merge was nightmare. People avoided doing work that would result a merge as it hurted to get it executed nicely.
  • rictic 7y ago
    My experience was very different. SVN was far slower than git. It was slower for me to checkout my company's SVN repo at head than to use git-svn to clone the entire SVN history locally. And from then on, most git operations were effectively instant, save for pushing and pulling to SVN. The killer feature though was that git didn't put my data at risk while I worked. With the normal SVN workflow, your working directory was the only copy of your changes. And when you sync'd with upstream it would modify the code in your working directory with merge information. Better hope that you get that merge right, because there's no second chances. Your original working directory state is gone forever, and it's up to you to recreate it with the pieces SVN hands you.
  • 7y ago
• baot 7y ago
  >Software development industry could gain a lot of productivity in the form of more sane de facto version control system, with saner defaults and better discoverability. So write it. I'm sorry to be so dismissive but it seems notable that those who like git get along with using it while those who complain about it just throw peanuts from the gallery. If it's obvious to you where git's flaws lie, it should be easy to write an alternative. If saner defaults and better discoverability are all you need, you don't even have to change the underlying structure, meaning you can just write a wrapper which will be found by all the competent developers whose productivity is so damaged that they do what they do when they encounter any problem and search the internet for a solution. It seems notable this hasn't happened.
• Zitrax 7y ago
  > However they were slower - but not much Depends, we went from CVS to Git and nightly jobs tagging the repository went from taking hours to being almost instant.
• VectorLock 7y ago
  About a year ago I dropped into a place that was still using SVN. Now they're switching to Git. This experience has really shown me how much SVN just gets out of the way compared to git-- much less I had to think about when using it.