6 ms·

Git the fsck out

24 points by tortilla 18y ago

makecheck 18y ago
It would seem that some of these git "problems" can be solved the way you'd automate anything else in Unix...write your own scripts or aliases. Tools are not supposed to please everybody. (They can't, since for every person who loves the default configuration, there will be someone who doesn't.) If you can't remember that "foo -bar -baz -squareroot4515" is the command to do X, then make a shell alias or a script that performs these steps for you, and call it whatever you want.
- cosmo7 18y ago
  I think the point of the article was that he shouldn't have to edit his ssh settings to use Git.
  - KirinDave 18y ago
    And he doesn't have to. ssh-keys is just a convenience. Most of the complaints in this article can be restated as, "I haven't taken the time to understand my version control system and so every little thing I do is foreign and strange. Therefore I am resentful." With the multiple-user-account issue being more of a github logistics than anything else (if you host your own repo, you have the entire unix permissions model is available to you). Everyone knows git is weird and new and has a much more complex interface than SVN, but the tradeoff is that you get an extremely powerful and flexible version control system.
    - DenisM 18y ago
      >> "I haven't taken the time to understand my version control system and so every little thing I do is foreign and strange. Therefore I am resentful." It seems to me you look down on such opinion? That's what usability is about - make things easy enough to learn so that users are not recentful.
      - KirinDave 18y ago
        >> It seems to me you look down on such opinion? That's what usability is about - make things easy enough to learn so that users are not recentful. We're software engineers. It is our job to understand more complex software models. Git's usability isn't terrible, it is just a more complex model that requires a more thorough understanding of the underlying principles. And given how trivial it is to find and read such data, my sympathy is limited. What's more, git's usability is a radical improvement path. Between services for remote repos (like github and gitorious) and better and better command line tools (GitX, for example). At some point you have to bite the bullet and understand your tools. We're seeing a lot of this reluctance in the industry as people are forced to confront distributed concepts.
        DenisM 18y ago
        I guess the question is which part of the learning curve is there for a reason and which part is preventable. Someone has already asked the question - is Mercurial any less powerful for being easier to use? I am sitting on the sidelines (svn) and waiting for the dust to settle. My only interest is to have one dcvs emerge with all the best in it that this field can offer.
        KirinDave 18y ago
        Mercurial is marginally less powerful (it's maybe 6 months behind git in features, perpetually). This is not a deal-breaker (except that I don't like Mercurial's equivalent of cheap local branches, these patch queues are just an awkward model for thinking about it), but then there is the speed issue. Git is incredibly fast, so fast that you almost never notice it working even for massive amounts of data.
        timr 18y ago
        "We're software engineers. It is our job to understand more complex software models. Git's usability isn't terrible, it is just a more complex model that requires a more thorough understanding of the underlying principles." My job is not to spend time understanding how to use the version-control flavor of the week -- my job is to write software. You may not realize it, but you're advancing the usual, dressed-up, ad hominem attack of the perspective-challenged nerd: "tool Y is EASY if you just try to learn it!" (the implication being that if you don't want to spend time on a yak-shaving expedition to learn tool Y -- when tool X works just fine -- then you're lazy, dumb, or both.) Version control is a tool. Good tools let me do my job and get out of the way. Bad tools force me to spend a lot of time "understanding" them before I can be productive.
qhoxie 18y ago
His problems seem to be directed more at GitHub and Unfuddle than git itself. Things like deleting a remote branch are not especially esoteric, so it seems like he just has trouble adjusting to the new way of thinking in git. That is fine, but his assessment of it is about as far from objective as possible.
jrockway 18y ago
But, every single time I want to do something, I have to look up a whole slew of commands. Why can’t I just memorize them? Because they’re horribly arcane and obtuse. I don't think this has anything to do with Git. I remember the commands just fine, without having to use Google.
- DenisM 18y ago
  So a Microsoft engineer is drafted to the army. On the shooting range he can't hit the target at all. When sergeant notifies him of zero hits, the engineer puts his finger into the rifle's barrell and pulls the trigger. His finger is ripped off. After evaluating the finger engineer turns to the sergeant and says: - On my side everything is fine - bullets are flying out. The problem is with the targets.
  - jrockway 18y ago
    That's a nice story, but it doesn't apply here. The guy who wrote the article is just dumb.
- run4yourlives 18y ago
  http://en.wikipedia.org/wiki/Ad_hominem http://en.wikipedia.org/wiki/Ad_hominem
- jodrellblank 18y ago
  That you can remember how to do something is not an argument for that being the best way to do said something, or even a good way to do it. The only good arguments for not making things simpler are "they cannot be any simpler", closely followed by "the tradeoffs aren't worth the effort/cost". Why not simplify everything, where possible? It's not about dumbing down, it's about being able to do more in total because each step is easier.
- sh1mmer 18y ago
  I think there is a lot to be said for intuitive tool design. While the article was particularly single sided, for something you should use as much as version control it should be low barrier. I rather like the Bazaar single binary approach with inline help on commands.
ohhmaagawd 18y ago
we just started a new project and we tried out git briefly. our prob with git is it supports ssh auth only (not HTTP Auth), which is retarded. makes setting up new users a pain. and leading non-techies thru setting it up is quite a challenge. the other major prob is lack of windows support. the people coding git clearly don't care about average joe users, just unix geeks. don't forget, there are a lot of people who use source control that have never opened a command line in their life (like designers, doc people). Because of these issues we had to switch to subversion....
- epall 18y ago
  And Subversion is perfectly appropriate for your uses! TortoiseSVN is a snap to use (and it's not the only great svn GUI out there), and Subversion seems to make sense to people. The only reason I see to use git is if you're trying to keep a bunch of developers who are running off in different directions to maintain a somewhat coherent codebase. Or if developers want their own playground. Even then, though, I worked at a company that used centralized Subversion, but almost every developer used git-svn locally. Different tools for different applications!
run4yourlives 18y ago
I'm still not understanding the big fuss about git. Okay, distributed source control is wonderful for OSS communities, but I'm not really seeing the point for a proprietary piece of software built by a small team. Perhaps I just don't understand source control enough, but the fact remains that for me, svn has never really given me any want, really. There's just no reason for me to change.
- dzorz 18y ago
  How about working on your own laptop, committing changes locally, fixing wrong/broken commits, and then seamlessly merging your changes with others. It is also much faster (e.g. try using svn blame), stores all the history locally, makes working on different branches very, very easy, etc.
- jbert 18y ago
  The major win is that a DVCS decouples the "commit as save work-in-progress" from the "commit a carefully polished jewel of a changeset which will live for eternity in the revision history". i.e. you can commit locally frequently, and push refined changesets upstream. The best of both worlds. Other top benefits include sideways pushing (work on desktop A & B, push work-in-progress between them without polluting the central repo). Yes, you can get a lot of the DVCS benefits from giving people personal, scratch brances in a central CVS, but for various social and technical reasons that seems to rarely happen.
  - run4yourlives 18y ago
    I suppose that's where I just don't understand things: What benefit does committing locally bring? Why not just not commit at all until you have that "carefully polished jewel"? Unless of course you're working on a change large enough to justify it's own branch, in which case the point is moot. The sideways push I get, but given that I use a laptop I find it irrelevant to me.
    - DarkShikari 18y ago
      Because you no longer have to think much before committing. You don't have to spend hours reviewing the code and having others look over the patch before you push it to the main tree: you can just commit it locally and go work on something else. Then, later, you might get an idea on how to improve your previous change. You go and amend it. And so forth. Eventually, you have a set of changes that's ready to be committed and which you have used locally for long enough that you can tell it doesn't break anything obvious. Then, you go through the code review, and finally push the changes. With a completely centralized system, you have one of the following going on: A. You don't actually do code reviews before pushing changes, and trunk is broken half the time. B. You wait all the time on your changes being reviewed, and you can't commit them until they have been. C. You revert to tarballs and diffs for dealing with different changesets. I was forcibly pushed into using git from svn, but now I'd never go back: its simply so much easier to say "OK, I'm done with this change, I'll commit it!" and not have to wait for everyone else to be in the office/online/available to look at the changes before I do so. This is especially important when dealing with separate changesets that necessary depend on each other, where you can't merely make a new branch for the new change because it requires the old changes.
DenisM 18y ago
Many of the comments here and on the blog itself are perfect demonstrations of developers' disdain for usability and oridnary users. "Is it hard to use? Works for me. Man up and study, Nancy!". Good grief.
- tdavis 18y ago
  Version control in general is not meant for "ordinary users"; it's for developers. I mean, sure, it can serve as a versioning system for just about anything, but it is overwhelmingly used for code. Git doesn't need to be easy for my Dad to use because he has no use for it. Despite having lived partially on the command line for nearly a decade now, there are still commands that are simply not intuitive to me. This isn't the developers' fault, it's my fault for not becoming more familiar with the commands and understanding why they actually make sense. find $directory -type f -name '<asterick>' -exec mv {} $directory2/. \; If you want to move thousands of files and can't use a single mv command, something like this will work. Most of it makes sense to me, but what's with the {}? That doesn't seem intuitive. And what about the extra /. \ crap? I would never think to add that junk and without it (iirc) the command returns some esoteric error. I'm sure if I read the proper manpages, I could figure out what purpose those seemingly extraneous symbols serve.
  - DenisM 18y ago
    As others mentioned, cvs is not just for developers, it's also for doc writers, lawyers, UI testers and designers. All that goes into a product must be versioned. But fine, let's say it's for developers only. Did you notice that the article is written by a developer? Clearly GIT is too difficult for some of its core aduience - developers. Blaming the user is not the way to build something people want.
    - tdavis 18y ago
      Yes, some, but not most. I switched from Subversion to Git myself a couple months ago and it took a week or two, but I learned "the git way" of doing things. Yes, I would need to look up the command to remove a remote branch, but I haven't done it in weeks and didn't commit it to memory the first time so that's understandable. Building something people want doesn't really need to be a goal of open-source software. Most software is built in the first place to solve a need of the person or people building it. Since they're not getting paid, what do they care if everybody wants to use it? A large majority of people seem to like Git. There will always be those who do not and I'm sure everybody has something they dislike about it. The difference is, Git is not commercial software, so making it more usable need not be an overwhelming goal -- although, you could fork it and make it your goal.
thwarted 18y ago
It seems you could replace all occurrences of subversion with cvs and all occurrences of git with subversion and you'd have a blog post you could date 2001.
- gjm11 18y ago
  Um, no. Because the specific complaints the author is making about git (compared with svn) aren't in fact ways in which svn is worse than CVS. If you didn't like Subversion (and preferred CVS) in 2001 it was because it was too new, because you'd heard scary stories of repository corruption, because you didn't like having a single revision number for your whole repository, that sort of thing. The only one of those that's at all parallel to any of what Micah is saying about git is the last one. Now, sure, both Micah's complaint now and an anti-svn complaint in 2001 fit the template "There's this cool new thing, and I'm not convinced it's an improvement on its predecessor". But, guess what, Micah said more than that, and the actual point is in the specific complaints he made, not in the fact "someone thinks something isn't better than what it's allegedly a better replacement for".

24 points by tortilla 18y ago

It would seem that some of these git "problems" can be solved the way you'd automate anything else in Unix...write your own scripts or aliases. Tools are not supposed to please everybody. (They can't, since for every person who loves the default configuration, there will be someone who doesn't.) If you can't remember that "foo -bar -baz -squareroot4515" is the command to do X, then make a shell alias or a script that performs these steps for you, and call it whatever you want.

cosmo7 18y ago
I think the point of the article was that he shouldn't have to edit his ssh settings to use Git.
- KirinDave 18y ago
  And he doesn't have to. ssh-keys is just a convenience. Most of the complaints in this article can be restated as, "I haven't taken the time to understand my version control system and so every little thing I do is foreign and strange. Therefore I am resentful." With the multiple-user-account issue being more of a github logistics than anything else (if you host your own repo, you have the entire unix permissions model is available to you). Everyone knows git is weird and new and has a much more complex interface than SVN, but the tradeoff is that you get an extremely powerful and flexible version control system.
  - DenisM 18y ago
    >> "I haven't taken the time to understand my version control system and so every little thing I do is foreign and strange. Therefore I am resentful." It seems to me you look down on such opinion? That's what usability is about - make things easy enough to learn so that users are not recentful.
    - KirinDave 18y ago
      >> It seems to me you look down on such opinion? That's what usability is about - make things easy enough to learn so that users are not recentful. We're software engineers. It is our job to understand more complex software models. Git's usability isn't terrible, it is just a more complex model that requires a more thorough understanding of the underlying principles. And given how trivial it is to find and read such data, my sympathy is limited. What's more, git's usability is a radical improvement path. Between services for remote repos (like github and gitorious) and better and better command line tools (GitX, for example). At some point you have to bite the bullet and understand your tools. We're seeing a lot of this reluctance in the industry as people are forced to confront distributed concepts.
      - DenisM 18y ago
        I guess the question is which part of the learning curve is there for a reason and which part is preventable. Someone has already asked the question - is Mercurial any less powerful for being easier to use? I am sitting on the sidelines (svn) and waiting for the dust to settle. My only interest is to have one dcvs emerge with all the best in it that this field can offer.
        KirinDave 18y ago
        Mercurial is marginally less powerful (it's maybe 6 months behind git in features, perpetually). This is not a deal-breaker (except that I don't like Mercurial's equivalent of cheap local branches, these patch queues are just an awkward model for thinking about it), but then there is the speed issue. Git is incredibly fast, so fast that you almost never notice it working even for massive amounts of data.
      - timr 18y ago
        "We're software engineers. It is our job to understand more complex software models. Git's usability isn't terrible, it is just a more complex model that requires a more thorough understanding of the underlying principles." My job is not to spend time understanding how to use the version-control flavor of the week -- my job is to write software. You may not realize it, but you're advancing the usual, dressed-up, ad hominem attack of the perspective-challenged nerd: "tool Y is EASY if you just try to learn it!" (the implication being that if you don't want to spend time on a yak-shaving expedition to learn tool Y -- when tool X works just fine -- then you're lazy, dumb, or both.) Version control is a tool. Good tools let me do my job and get out of the way. Bad tools force me to spend a lot of time "understanding" them before I can be productive.

qhoxie 18y ago

His problems seem to be directed more at GitHub and Unfuddle than git itself. Things like deleting a remote branch are not especially esoteric, so it seems like he just has trouble adjusting to the new way of thinking in git. That is fine, but his assessment of it is about as far from objective as possible.

jrockway 18y ago

But, every single time I want to do something, I have to look up a whole slew of commands. Why can’t I just memorize them? Because they’re horribly arcane and obtuse. I don't think this has anything to do with Git. I remember the commands just fine, without having to use Google.

DenisM 18y ago
So a Microsoft engineer is drafted to the army. On the shooting range he can't hit the target at all. When sergeant notifies him of zero hits, the engineer puts his finger into the rifle's barrell and pulls the trigger. His finger is ripped off. After evaluating the finger engineer turns to the sergeant and says: - On my side everything is fine - bullets are flying out. The problem is with the targets.
- jrockway 18y ago
  That's a nice story, but it doesn't apply here. The guy who wrote the article is just dumb.
run4yourlives 18y ago
http://en.wikipedia.org/wiki/Ad_hominem http://en.wikipedia.org/wiki/Ad_hominem
jodrellblank 18y ago
That you can remember how to do something is not an argument for that being the best way to do said something, or even a good way to do it. The only good arguments for not making things simpler are "they cannot be any simpler", closely followed by "the tradeoffs aren't worth the effort/cost". Why not simplify everything, where possible? It's not about dumbing down, it's about being able to do more in total because each step is easier.
sh1mmer 18y ago
I think there is a lot to be said for intuitive tool design. While the article was particularly single sided, for something you should use as much as version control it should be low barrier. I rather like the Bazaar single binary approach with inline help on commands.

ohhmaagawd 18y ago

we just started a new project and we tried out git briefly. our prob with git is it supports ssh auth only (not HTTP Auth), which is retarded. makes setting up new users a pain. and leading non-techies thru setting it up is quite a challenge. the other major prob is lack of windows support. the people coding git clearly don't care about average joe users, just unix geeks. don't forget, there are a lot of people who use source control that have never opened a command line in their life (like designers, doc people). Because of these issues we had to switch to subversion....

epall 18y ago
And Subversion is perfectly appropriate for your uses! TortoiseSVN is a snap to use (and it's not the only great svn GUI out there), and Subversion seems to make sense to people. The only reason I see to use git is if you're trying to keep a bunch of developers who are running off in different directions to maintain a somewhat coherent codebase. Or if developers want their own playground. Even then, though, I worked at a company that used centralized Subversion, but almost every developer used git-svn locally. Different tools for different applications!

run4yourlives 18y ago

I'm still not understanding the big fuss about git. Okay, distributed source control is wonderful for OSS communities, but I'm not really seeing the point for a proprietary piece of software built by a small team. Perhaps I just don't understand source control enough, but the fact remains that for me, svn has never really given me any want, really. There's just no reason for me to change.

dzorz 18y ago
How about working on your own laptop, committing changes locally, fixing wrong/broken commits, and then seamlessly merging your changes with others. It is also much faster (e.g. try using svn blame), stores all the history locally, makes working on different branches very, very easy, etc.
jbert 18y ago
The major win is that a DVCS decouples the "commit as save work-in-progress" from the "commit a carefully polished jewel of a changeset which will live for eternity in the revision history". i.e. you can commit locally frequently, and push refined changesets upstream. The best of both worlds. Other top benefits include sideways pushing (work on desktop A & B, push work-in-progress between them without polluting the central repo). Yes, you can get a lot of the DVCS benefits from giving people personal, scratch brances in a central CVS, but for various social and technical reasons that seems to rarely happen.
- run4yourlives 18y ago
  I suppose that's where I just don't understand things: What benefit does committing locally bring? Why not just not commit at all until you have that "carefully polished jewel"? Unless of course you're working on a change large enough to justify it's own branch, in which case the point is moot. The sideways push I get, but given that I use a laptop I find it irrelevant to me.
  - DarkShikari 18y ago
    Because you no longer have to think much before committing. You don't have to spend hours reviewing the code and having others look over the patch before you push it to the main tree: you can just commit it locally and go work on something else. Then, later, you might get an idea on how to improve your previous change. You go and amend it. And so forth. Eventually, you have a set of changes that's ready to be committed and which you have used locally for long enough that you can tell it doesn't break anything obvious. Then, you go through the code review, and finally push the changes. With a completely centralized system, you have one of the following going on: A. You don't actually do code reviews before pushing changes, and trunk is broken half the time. B. You wait all the time on your changes being reviewed, and you can't commit them until they have been. C. You revert to tarballs and diffs for dealing with different changesets. I was forcibly pushed into using git from svn, but now I'd never go back: its simply so much easier to say "OK, I'm done with this change, I'll commit it!" and not have to wait for everyone else to be in the office/online/available to look at the changes before I do so. This is especially important when dealing with separate changesets that necessary depend on each other, where you can't merely make a new branch for the new change because it requires the old changes.

DenisM 18y ago

Many of the comments here and on the blog itself are perfect demonstrations of developers' disdain for usability and oridnary users. "Is it hard to use? Works for me. Man up and study, Nancy!". Good grief.

tdavis 18y ago
Version control in general is not meant for "ordinary users"; it's for developers. I mean, sure, it can serve as a versioning system for just about anything, but it is overwhelmingly used for code. Git doesn't need to be easy for my Dad to use because he has no use for it. Despite having lived partially on the command line for nearly a decade now, there are still commands that are simply not intuitive to me. This isn't the developers' fault, it's my fault for not becoming more familiar with the commands and understanding why they actually make sense. find $directory -type f -name '<asterick>' -exec mv {} $directory2/. \; If you want to move thousands of files and can't use a single mv command, something like this will work. Most of it makes sense to me, but what's with the {}? That doesn't seem intuitive. And what about the extra /. \ crap? I would never think to add that junk and without it (iirc) the command returns some esoteric error. I'm sure if I read the proper manpages, I could figure out what purpose those seemingly extraneous symbols serve.
- DenisM 18y ago
  As others mentioned, cvs is not just for developers, it's also for doc writers, lawyers, UI testers and designers. All that goes into a product must be versioned. But fine, let's say it's for developers only. Did you notice that the article is written by a developer? Clearly GIT is too difficult for some of its core aduience - developers. Blaming the user is not the way to build something people want.
  - tdavis 18y ago
    Yes, some, but not most. I switched from Subversion to Git myself a couple months ago and it took a week or two, but I learned "the git way" of doing things. Yes, I would need to look up the command to remove a remote branch, but I haven't done it in weeks and didn't commit it to memory the first time so that's understandable. Building something people want doesn't really need to be a goal of open-source software. Most software is built in the first place to solve a need of the person or people building it. Since they're not getting paid, what do they care if everybody wants to use it? A large majority of people seem to like Git. There will always be those who do not and I'm sure everybody has something they dislike about it. The difference is, Git is not commercial software, so making it more usable need not be an overwhelming goal -- although, you could fork it and make it your goal.

thwarted 18y ago

It seems you could replace all occurrences of subversion with cvs and all occurrences of git with subversion and you'd have a blog post you could date 2001.

gjm11 18y ago
Um, no. Because the specific complaints the author is making about git (compared with svn) aren't in fact ways in which svn is worse than CVS. If you didn't like Subversion (and preferred CVS) in 2001 it was because it was too new, because you'd heard scary stories of repository corruption, because you didn't like having a single revision number for your whole repository, that sort of thing. The only one of those that's at all parallel to any of what Micah is saying about git is the last one. Now, sure, both Micah's complaint now and an anti-svn complaint in 2001 fit the template "There's this cool new thing, and I'm not convinced it's an improvement on its predecessor". But, guess what, Micah said more than that, and the actual point is in the specific complaints he made, not in the fact "someone thinks something isn't better than what it's allegedly a better replacement for".