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.



  • 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)


  • @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.


  • SockDev

    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?



  • 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.



  • 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 undefined button", steps 6-8 can be replaced with "click the 'I want to make a pull request' button before you click the the undefined 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


  • SockDev

    @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*

    <!-- Emoji'd by MobileEmoji 0.2.0-->


  • 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.


  • SockDev

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

    <!-- Emoji'd by MobileEmoji 0.2.0-->


  • @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.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.