Well-reasoned anti-Git article



  • I like the bit about usability:

    Here’s a tip: if you say something’s hard, and everyone starts screaming at you—sometimes literally—that it’s easy, then it’s really hard. The people yelling at you are trying desperately to pretend like it was easy so they don’t feel like an idiot for how long it took them to figure things out. This in turn makes you feel like an idiot for taking so long to grasp the “easy” concept, so you happily pay it forward, and we come to one of the two great Emperor Has No Clothes moments in computing.


  • ♿ (Parody)

    Note: we fell in love with DVCSes because they got branching right, but there’s nothing inherently distributed about a VCS with sane branching and merging.

    Yes, this is a big reason why existing DVCSes are better than things like subversion, but it's an implementation detail. I've said this a lot.

    I have wanted to have the full history while offline a grand total of maybe about six times. And this is merely going down over time as bandwidth gets ever more readily available.

    I've wanted them a lot more than that. I can accept that many people function that way, but this is merely personal preference / circumstance. I haven't worked with any truly massive repos, but this is certainly a drawback of a DVCS.

    The github ranting is pretty irrelevant to me. I've never used it, so maybe it's all very legit about the way it's used, but that doesn't say much about DVCS.

    I wasn't aware of Facebook working with Mercurial (my DVCS of choice). I'm pretty happy about that, as I've worried that the git love-in might doom it.



  • His argument basically is threefold:

    1. DVCSes don't scale to huge repositories -- this is the only thing that I can see as a legitimate point: Git and Hg both rely heavily on SHA-1 (i.e. contents) based techniques for several operations, and those are never going to be particularly snappy.
    2. DVCSes are hard to use -- this is an anti-Git argument that does not hold true for Hg, IME -- Hg's no harder to use than SVN.
    3. Blobs are a whole another story -- you should be storing the source form of all assets in your VCS, not just your source code. (I.e. instead of putting a compressed PNG of an icon in your repo -- you should have the Photoshop/GIMP/... file for that icon)

  • ♿ (Parody)

    @tarunik said:

    DVCSes don't scale to huge repositories

    One "easy" solution to this would seem to be not taking the entire history. The FB guys' idea is to fetch metadata and only get detail when you actually need it, which is another compromise. A bit of a hybrid model.

    @tarunik said:

    DVCSes are hard to use -- this is an anti-Git argument that does not hold true for Hg, IME

    I agree, except that some people still have a difficult time with the concepts involved with DVCS. But that's not really a tooling issue, from what I've seen. It's more a matter of people not being able to think beyond their CVCS experience.


  • FoxDev

    well for the record i do quite like git. i've been using it for years and i understand it.

    but when i was learning? i HATED it, bu that was less to do with git and more to do with my other classmates methods of resolving merge conflicts which was:

    • There's a conflict? just take my version it'll compile
    • the thing no longer compiles after the merge? play with rebase to try to get my version back to compiling
    • rebase broke the repo completely by making HEAD reference HEAD? complain to the professor that @accalia is stopping them from working effectively because she keeps making changes to their files and it keeps breaking source control!

    but i'll tell you. i got DAMN good at repairing broken git repos in that class. after that i think i may have developed stockholm syndrome with git.

    why am i still using git? oh right all my shit's already there.

    is there an easy way to import a git project into mercurial without losing commit/change history?


  • ♿ (Parody)

    I crapped 5 posts into a new repo: git shit



  • A couple of notes from the author of easy-git:

    ­

    ##How NOT to write user-friendly documentation
    ­
    Warning: This is essentially a long rant about the built-in help of git, but with specific problems pointed out and some constructive suggestions buried at the very end.

    ­

    Limbo: Why users are more error-prone with git than other VCSes

    ­
    Limbo is a term I use but VCS authors don’t. However, that’s because they tend to ignore a certain state that exists in all major VCSes (and give it no name because they tend to ignore it) despite the fact that this state seems to be the largest source of errors. I call this state limbo.



  • So according to the second article, svn add isn't a thing and also git is the only VCS to have adding files as a command.



  • @ben_lubar said:

    So according to the second article, svn add isn't a thing and also git is the only VCS to have adding files as a command.

    Yes, of course. That's the only possible interpretation of the article which makes sense.



  • Why, it also says Go is a terrible computer language and... wow this is incredible! ... it even says Ben L is a lame-o! Amazing.


  • ♿ (Parody)

    He has a very Jon Stewart way about him lately.



  • The OP has possibly the greatest footnote in the history of footnotes, though:

    1. And it is Git, because Git “won”, which it did because GitHub “won”, because coding is and always has been a popularity contest, and we are very concerned about either being on the most popular side, or about claiming that the only reason literally everyone doesn’t agree with us is because they’re stupid idiots who don’t know better. For a nominally nuanced profession, we sure do see things in binary.


  • Whereas with the GitHub pull-request model, you instead need to

    1. Fork the repository on GitHub
    2. Clone your fork of the source code
    3. Make sure you’re on the right branch that upstream expects your patch to be based on, because they totally won’t take patches on master if they expect them on dev or vice-versa.
    4. Make a new local branch for your patch
    5. Go ahead and make the patch
    6. Do a commit
    7. Push to a new branch on your GitHub fork
    8. Go to the GitHub UI and create a pull request
    9. Watch it get ignored

    Steps 1-4 can be replaced with "click the button", steps 6-8 can be replaced with "click the 'I want to make a pull request' button before you click the the button".

    It's not 9 steps versus 5 steps. It's 4 steps versus 5 steps. You can watch your patch get ignored so much faster.



  • I, too, like Hg


  • FoxDev

    @blakeyrat said:

    I like the bit about usability:

    Here’s a tip: if you say something’s hard, and everyone starts screaming at you—sometimes literally—that it’s easy, then it’s really hard. The people yelling at you are trying desperately to pretend like it was easy so they don’t feel like an idiot for how long it took them to figure things out. This in turn makes you feel like an idiot for taking so long to grasp the “easy” concept, so you happily pay it forward, and we come to one of the two great Emperor Has No Clothes moments in computing.


    Everything is easy in hindsight. Trouble is, it's easy to forget that…
    And as a result of the efforts of people like me, we’re now seeing some truly insane “best practices” in the name of adopting Git.5 And mind you, we insist they’re “best practices”; they’re not workarounds, oh no, they’re what you should have been doing since the beginning.

    And that’s bullshit.

    QFT; you pick the (D)VCS that fits your situation, not the one that all the cool kids are using.
    @accalia said:

    is there an easy way to import a git project into mercurial without losing commit/change history?

    Looks like there are ways (SO warning):
    But there's also the potential for issues.

    Whereas with the GitHub pull-request model, you instead need to

    1. Fork the repository on GitHub
    2. Clone your fork of the source code
    3. Make sure you’re on the right branch that upstream expects your patch to be based on, because they totally won’t take patches on master if they expect them on dev or vice-versa.
    4. Make a new local branch for your patch
    5. Go ahead and make the patch
    6. Do a commit
    7. Push to a new branch on your GitHub fork
    8. Go to the GitHub UI and create a pull request
    9. Watch it get ignored

    To be fair, that's not necessarily GitHub- or even Git-specific; if there's a GitHub equivalent for Mercurial (or even TFS or Subversion, or even CVS), you'd probably get the same issues 😕
    @JazzyJosh said:

    I, too, like Hg

    Me too 🙋


    I currently use both Git (for SockBot development) and Hg (at work), and so far, I've not really seen any substantial difference. But if I had to choose right now this very instant or I'll be shot in the head, I'd pick Hg. I found it really easy to pick up; it's almost like Subversion done right, and I got pretty comfortable with Subversion when I used it in a previous job.

    I like TFS too.
    *awaits pelting with stones*



  • Pretty good article.

    The only part I disagree with is this:

    No, the only thing that a DVCS gets you, by definition, is that everyone gets a copy of the full offline history of the entire repository to do with as you please.

    Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. And this is merely going down over time as bandwidth gets ever more readily available. If you work as a field tech, or on a space station, or in a submarine or something, then okay, sure, this is a huge feature for you. But for the rest of us, I am going to assert that this is not the use case you need to optimize for when choosing a VCS.

    I'm far from a git or even version control in general expert. I work in small teams and usually only use the basic features (little experience with cherry-picking, complicated merges, etc).

    But even I use the DVCS features all the time. It's such a relief being able to quickly branch off within your local repo and try something without bothering the central. Or just make a little commit every now and then, to clear up "changed files" visual indications inside my IDE.

    I know you can do all this with a SVN, but not without creating a mess on the central server, having to type boring-ass comments (because it's a public space now) and suffering network latency for every little thing you want to do.

    This guy can claim whatever he wants about git performance, but once my 100+ MB git repo gets downloaded, all the commands are blazing fast. This is not the case with similar-sized SVN repos I've worked with.


  • FoxDev

    Add in the convenience of being able to check in changes without having to connect to upstream; useful if you're suffering Internet issues 😄



  • @RaceProUK said:

    Add in the convenience of being able to check in changes without having to connect to upstream; useful if you're suffering Internet issues

    Yeah, his point is, this is not often the case. And I agree.

    My point is, even with stable internet, I appreciate being able to mess around in my local repo without creating a mess on origin/upstream.



  • [quote="RaceProUK, post:17, topic:856]
    useful if you're suffering Internet issues
    [/quote]

    So probably maybe once or twice a year, unless you're Ben Lubar.

    And as far as I know, there's also a big elephant in the room in that DVCSs aren't just supposed to provide you a local repo in addition to the central one, you can do that with a CVCS too - the intended use is for everyone to do peer-to-peer synchronization between those local repos, except nobody does that because it's fucking retarded.

    So people have already rejected the core concept of DVCSs, which is decentralization.



  • @Maciejasjmj said:

    And as far as I know, there's also a big elephant in the room in that DVCSs aren't just supposed to provide you a local repo in addition to the central one, you can do that with a CVCS too - the intended use is for everyone to do peer-to-peer synchronization between those local repos, except nobody does that because it's fucking retarded.

    Yeah I agree with that. I can see how decentralization would be theoretically useful, but...

    A few times I actually had a new branch on a local repo and wanted to pull it from the same repo in a different folder. But I was too lazy to look up command semantics and was afraid to screw up my established push/pull workflow. So I just pushed the new branch to central from one folder and pulled it from the other.

    So maybe decentralization could be made to work in practice, but apparently not with git's command interface.


  • FoxDev

    @Maciejasjmj said:

    So probably maybe once or twice a year, unless you're Ben Lubar.

    Or unless you work in my office; the Internet connection drops anything from once to five times a day 😕



  • @cartman82 said:

    My point is, even with stable internet, I appreciate being able to mess around in my local repo without creating a mess on origin/upstream.

    This.

    IMO, git svn is a decent solution. The central repo is a subversion one, but I can work against a (local) git repo. Others who prefer svn can use that directly too. And as with plain svn, git svn can check out a sub path of the repository.

    Repos that contain large files can be somewhat problematic, since the local git copy contains all of the history, but for code only, I kinda like it.



  • @cartman82 said:

    But even I use the DVCS features all the time. It's such a relief being able to quickly branch off within your local repo and try something without bothering the central. Or just make a little commit every now and then, to clear up "changed files" visual indications inside my IDE.

    As the guy who is responsible that the team's product actually gets delivered, I can tell you that anything you do locally doesn't count. One of my biggest frustrations with DVCSs in a corporate setting is that commits are pointless, I need you do push to the central repo in case you call in sick for a week straight and I have to go rooting through your computer (which hopefully isn't a laptop that you have at home) so someone can finish what you were working on.



  • @Jaime said:

    As the guy who is responsible that the team's product actually gets delivered, I can tell you that anything you do locally doesn't count. One of my biggest frustrations with DVCSs in a corporate setting is that commits are pointless, I need you do push to the central repo in case you call in sick for a week straight and I have to go rooting through your computer (which hopefully isn't a laptop that you have at home) so someone can finish what you were working on.

    Yeah. That's the point. I can finish a complete unit and then push that to the central. If someone else needs to take over, they are at least getting the code they can wrap their head around. Not some half-completed middle state where only I know what was taken apart and where things are going.

    Ideally, before a push, you should take all the throwaway commits and squash them into a few larger, well described ones, so that the progression of code can be followed through commit history. I presume serious larger teams are doing something like that.


  • FoxDev

    Does Hg allow you to squash commits together like that? And Git, for that matter.


  • Fake News

    I tend to fixup commits all the time during the day using git rebase --autosquash, though you should be wary of not breaking the central repository.


  • Discourse touched me in a no-no place

    @Jaime said:

    One of my biggest frustrations with DVCSs in a corporate setting is that commits are pointless, I need you do push to the central repo in case you call in sick for a week straight and I have to go rooting through your computer (which hopefully isn't a laptop that you have at home) so someone can finish what you were working on.

    As long as you've got a policy of “it isn't done if it isn't committed to the shared repo” it's not too bad; whatever they're doing doesn't count if they didn't commit, and they'll just have to Deal With It when they're back available to work. It'll probably irritate a few people the first few times, but the rule will benefit them when they're not blocked from working by someone else.

    I prefer to operate under an even stricter rule that only artefacts build by the CI system count — indeed, that I can't push anything I make myself to our build-results store — and that only listens to commits to the central repo. What I do locally is of interest to me, but others may ignore me as they see fit. (It's frustrating when it WOMM, and not on the CI server, but if it doesn't work there, how can I expect to work for anyone else?)



  • @RaceProUK said:

    I like TFS too.

    I'm guessing pretty much everybody involved in this debate has never used TFS 2013, because it's really, really damned good.



  • @cartman82 said:

    This guy can claim whatever he wants about git performance, but once my 100+ MB git repo gets downloaded, all the commands are blazing fast. This is not the case with similar-sized SVN repos I've worked with.

    The company I'm working for now has a git repo of about 2 GB with hundreds of thousands of files. Git is slow as shit on a repo that size, which is exactly the point he makes. (TFS 2013 on a larger repo, BTW, lightning fast.)

    100 MB repo is baby toy shit. Even our 2 GB repo is baby toy shit compared to something a company like Adobe would have.

    And Git doesn't have the ability to download selectively, like TFS/Subversion/etc. It's all or nothing. (Yes, yes, I'm sure someone's going to tell me some ugly hack to do it, I care not.)



  • @RaceProUK said:

    Add in the convenience of being able to check in changes without having to connect to upstream; useful if you're suffering Internet issues

    So I have to deal with the idiocy of Git because once every year my Internet might go down for 5 minutes?

    Protip: the idiocy of Git costs me a shitload more than 5 minutes a year. It cost me almost an hour just on Friday, although mainly due to someone at our company using the half-baked (to be generous, I'd say: "utterly broken") submodule feature.



  • @Jaime said:

    As the guy who is responsible that the team's product actually gets delivered, I can tell you that anything you do locally doesn't count. One of my biggest frustrations with DVCSs in a corporate setting is that commits are pointless, I need you do push to the central repo in case you call in sick for a week straight and I have to go rooting through your computer (which hopefully isn't a laptop that you have at home) so someone can finish what you were working on.

    I've bitched about Git not having the option for an "online only mode" before, and yes, this is exactly why. Companies I've worked at in the past have had exactly this problem.


  • FoxDev

    @blakeyrat said:

    So I have to deal with the idiocy of Git because once every year my Internet might go down for 5 minutes?

    It's not exclusive to Git; all DVCSs have that ability. And for some people, it's important.



  • @RaceProUK said:

    It's not exclusive to Git; all DVCSs have that ability. And for some people, it's important.

    I know that. We've had this debate before.

    The problem isn't that Git has the ability to work offline. That's a fine feature, I'm sure tons of people enjoy it. The problem is that Git has no ability to work online. That's a feature virtually every other VCS has but is only a giant gaping void in Git.

    There's no technical reason it couldn't have both. The reason it doesn't have both is: Git was developed by idiot dumbshits who have no clue what the fuck they are even doing, goddamned.


  • Discourse touched me in a no-no place

    @RaceProUK said:

    Add in the convenience of being able to check in changes without having to connect to upstream

    How is checking in locally, which then still needs pushing upstream different to just having the files on my laptop until I can connect to the upstream server?



  • The only reason you even need to do that (in my experience) is to switch branches-- because Git is too fucking stupid/idiot/dumb to cope with switching branches with uncommitted changes, another misfeature that bites me in the ass almost every day.

    Last week my boss told me to clean up all my branches for bugs that didn't require any code changes to solve. These clutter up our server because when I start investigating a bug on "develop" I don't yet know whether it'll require code changes or not-- after being bitten in the ass like 5 times over having to somehow port changes from "develop" to the bug branch (because Git throws a huge hissy-fit), I just pro-actively create the bug branch first now and switch to it even before doing any investigation. Then we end up with tons of leftover branches with no commits in them, when I then have to go in and manually clean-up. (ANOTHER WAY GIT SAVES ME SO MUCH TIME! BORING JANITORIAL WORK!)

    It seems like the Git designers (to be generous) didn't anticipate people switching branches 20 times a day, because that's almost physically painful in Git.


  • FoxDev

    I would imagine for the same reason you use a VCS in the first place: tracking changes. I can imagine it's especially useful if you need to roll back some changes without backing out others; instead of throwing away all changes, or messing up a manual rollback, you just make a couple of clicks (or issue a command or two) and it's done reliably and atomically.



  • And then you get detached head and then Git somehow marks every single file inside the submodule as "changed" because it's too stupid to figure out it's a submodule and then you throw your computer out the window and become a monk.


  • FoxDev

    Must be a Git-specific thing; never had the detached head issue in Hg.


  • ♿ (Parody)

    Yes, detached heads are a git-ism. Hg just happily creates a new anonymous branch and you can deal with it sanely later by either merging it with the main branch or closing it or whatever.



  • So, there are two main issues here:

    • DVCS vs CVCS—with the exception of the vanishingly small class of developers who can apparently only work while they're actually flying from one airport to another, centralized VCS is generally what most corporations and organizations want.

    • Git in particular has some spectacularly poor choices in terminology which makes it actively confusing for developers familiar with other VCSs.


  • ♿ (Parody)

    Two other important issues are really just implementation details (which we kind of talked about and so did the article). One reason to go with git / hg and away from svn is svn is shit for branches and it's actively evil merge-then-commit paradigm.

    It sounds like Facebook's work on hg removes the big repo problem as a reason to stick with svn.



  • Could be. I've never run into any issues with svn merge (although I've never attempted to merge with a svn < 1.7, or into a branch with local changes, so...)

    If hg's CLI is close enough to svn's that I can just switch with the minimum of effort (and also, if some approximation of TortoiseHG exists), then I wouldn't be too fussed about staying with Subversion just for sentimental reasons.

    Then again, there's always fossil...


  • FoxDev

    @tar said:

    if some approximation of TortoiseHG exists

    Are you looking for TortoiseHg maybe?

    Or are you looking for a Linuxy something?



  • @RaceProUK said:

    @tar said:
    if some approximation of TortoiseHG exists

    Are you looking for TortoiseHg maybe?

    No, I had something completely different in mind.



  • @tar said:

    DVCS vs CVCS (...)

    But "having a local repository" is not a difference between DVCSs and CVCSs. You can easily have a CVCS with local repo copies which get synchronized with the central server.

    The defining difference between the two is that in a DVCS, you're supposed to do a peer-to-peer patch exchange, instead of having a separate server which everyone consults. The local repos are just a side-effect of that.

    So to me, the whole concept of a DVCS is pretty much dead.


  • ♿ (Parody)

    @tar said:

    Could be. I've never run into any issues with svn merge (although I've never attempted to merge with a svn < 1.7, or into a branch with local changes, so...)

    It's directory focused nature makes things more difficult than they need to be. As TFA says, they're kind of addressing this. However, there's still the problem of working in the same branch as other people, where issuing an update causes a merge to happen to the changes in your code.

    Oops, it fucked up something you were working on? Sucks to be you. You have no record of what stuff was before the update. I guess this is something git's unique model could account for if you added your changes before updating.



  • I suppose you could make the case that having a copy of the whole source tree on every developer's PC is useful if your central server and backups vanish into the night, but you're probably better off setting up proper backups in the first place.

    But yeah, having each developer having their own unique special snowflake tree is not going to go well in most cases.



  • @boomzilla said:

    One reason to go with git / hg and away from svn is svn is shit for branches and it's actively evil merge-then-commit paradigm.

    Actively evil.

    I've used SVN for like 10 years and never had a problem with merges. I've used Git for like 3 years and have had approximately 40,000 problems with merges.

    I'll take "actively evil" if it FUCKING WORKS.


  • ♿ (Parody)

    @blakeyrat said:

    I'll take "actively evil" if it FUCKING WORKS.

    That's the point. It doesn't really, and can easily fuck you over and destroy data. I know that you can't comprehend what I posted before, and I don't deny that you've had problems with git's obscure ways. That you haven't had problems with svn just tells me that you've been able to avoid serious branching and have avoided having people working simultaneously on the same parts of the system.

    Of course, for lots of people, git apparently works.



  • @tar said:

    I suppose you could make the case that having a copy of the whole source tree on every developer's PC is useful if your central server and backups vanish into the night

    But again, you can do it with a local repo and a CVCS. In fact, you pretty much can't do it in a DVCS, because in a DVCS there's no central server at all, and the way people use Git is Doing It Wrong (or in this case, hacking it into something workable).

    It's like... Imagine a bizarro world, in which WYSIWYG editors were never invented and people use Markdown for all text formatting purposes (inb4 "how would that world even survive without launching into insanity"). And you're the first person to invent the first WYSIWYG text editor. And as a part of that editor, you included an awesome image editing module, which rivals Photoshop and beats GIMP hands down.

    You put it on the market, and it turns out people do use your product... for typing Markdown in, then saving the file as .md and feeding it to the Markdown parser. They also like the image editor, but instead of embedding images into the file, they save them to disk and type in their <img src... tags as they did before.

    Sure, you made a good product, and you made an useful feature which no other product on the market has. But it's not because it's a WYSIWYG editor - in fact, most people don't even know it's a WYSIWYG editor, find the concept just as useless and alien as it was before, and actively refuse to use it as such. And you haven't popularized the concept of WYSIWYG editors, and anyone who argues that "WYSIWYG editors are better because they have more advanced image editors" is just flat out wrong.

    That's what happened to the whole DVCS shtick.


Log in to reply