10 ms·

All the people suggesting various git commands he should be using are completely missing the point.

by Qz 16y ago

IsaacSchlueter 16y ago
The point being that the author isn't looking for solutions, but rather just wants to bitch?
- Qz 16y ago
  The point being that the solutions are problematic.
  - itistoday 16y ago
    And the problems shouldn't exist in the first place.
    - MikeTaylor 16y ago
      But, yes, I do also like to bitch about them :-)
      - ableal 16y ago
        Watch out for the flying door-knobs. ( http://news.ycombinator.com/item?id=1272779 http://news.ycombinator.com/item?id=1272779 ) Seems that the peasants who have binaries should use rsync manually, instead of expecting tools to do the job.
    - donaq 16y ago
      Linus didn't write git for you. He wrote it for himself. Git works exactly the way Linus (and his merry band of kernel hackers (and others, who thought DVCS was a cool idea when they heard about it and were prepared to relearn SCM to use it)) wants it to work. If you want to learn to use it, cool, welcome to the party. If you aren't prepared to invest the time, that's cool too. But don't try it for like a day expecting it to be svn++ and then complain that it isn't. That's like a Windows user declaring that Linux sucks because it isn't Windows. It wasn't meant to be. Although, complaining about Ubuntu not doing things the way they "should" is more valid, since Ubuntu is targeted at everyone. :)
      - viraptor 16y ago
        Git is gaining a lot of attention lately. It's becoming "the dvcs" now. And that means, if you start using it for your project, you should consider what does it mean for contributors / users. If it creates an additional step where someone will say - "it will take me more time to learn, than creating the patch itself", you've lost. If many people start using git, we can start expecting things from git. It's just not about an abstract "you" anymore.
        donaq 16y ago
        If many people start using git, we can start expecting things from git. Why? The author of a piece of software is under no obligation to satisfy the expectations of its incidental users, especially if he's not selling it to them.
        viraptor 16y ago
        If they get big enough... no they don't have an obligation, but the idea of many people depending on them should be enough. It's like MS had no obligation to satisfy expectations of IE5 users (not sold directly) - sure they didn't - but many got very annoyed because of that and because of the market share, we had internet-wide consequences for standard-compliant websites. Still - they had no obligation.
        donaq 16y ago
        That is just wrong on so many levels. Firstly, Microsoft marketed the hell out of IE. The bundling of IE with Windows was their way of getting people to use IE instead of Netscape Navigator. Since their stand (in court, no less!) was that IE was an integral part of Windows, which they sold to users, they did have an obligation to satisfy users' expectations of it. Did anyone force you to use git by bundling it with some other piece of software you were using? Nope. Secondly, in what crazy alternate universe can git, which is given to you free as in libre as well as beer, be compared with IE? If you think git sucks, but still want to use it for some crazy reason, go ahead and modify it to suit your needs. Lastly, I cannot imagine a world where anyone would be forced to have to cater for a VCS the way we have to for browsers. They're simply too different in function. It's not like you're in danger of being forced into the business of implementing a service supporting commits and checkouts for two different types of repositories on the same source files... unless you work at GitHub. Heh.
itistoday 16y ago
Thank you. I suspect these folks were OK with spending hours learning about their DVCS, but for most others, this just seems like unnecessary tedium and frustration, "When can I get back to worrying about the code?" Someone needs to make the Mac of a DVCS, i.e. one that doesn't require a 20+ page tutorial to figure out, is completely intuitive and "just works." I currently use Mercurial, and while I don't think it qualifies as the Mac of DVCS's, it seems to be working decently enough so far (for my simple purposes). I could learn git, but thanks to hg-git I'm hoping I won't have to.
- avar 16y ago
  Why yes, a lot of us are just fine spending "hours" learning something that we'll probably spend more than a few years using. Git's user interface isn't perfect, but you're not going to get the "Mac of DVCSs" either. There's a reason for the complexity, doing stuff like merging together the work of three people is inherently complex. You're not going to come up with some solution that allows the user to "just do it" without also destroying history.
  - viraptor 16y ago
    > You're not going to come up with some solution that allows the user to "just do it" without also destroying history. Really? I've got state A and state B. I tell my DVCS to merge them into state C. After reviewing the automatically guessed changes and manually changing the things which could not be guessed, I commit C'. C' is successor to both A and B. What exactly has been lost / destroyed here?
    - ekiru 16y ago
      Nothing. Conveniently, git allows you to do exactly that. 1. Checkout B. 2. Merge A into B. 3. Git tells you there's a merge conflict and what to do to fix it: "Auto-merging foo CONFLICT (content): Merge conflict in foo Automatic merge failed; fix conflicts and then commit the result." 4. Edit foo and fix the conflict. 5. "git add foo" 6. Commit. What's the problem?
pyre 16y ago
The point -- as I understand it -- is that the author feels that a version control system should act like X. So he takes a random version control system, reads about it briefly, and then tries to use it assuming that it acts like X. The version control system doesn't act like X, which leads to problems for the author. Author writes a blog post about how random version control system sucks because it doesn't meet his assumptions.
- Xurinos 16y ago
  That is what I got out of it. A big clue was his "git commit filename". git is not svn. Is git's greatest sin really that it uses a few of the same words with different meanings from how they have been used in the past? Someone in another post mentioned revert. svn revert file == git checkout file, while git revert patches out a whole change. It actually makes sense if you forget about cvs and svn's version of the API. I saw the word "intuitive" thrown around... http://www.asktog.com/papers/raskinintuit.html http://www.asktog.com/papers/raskinintuit.html
  - phaylon 16y ago
    You mean it actually makes sense if you forget the other VCS versions of that command, and know git's? Because ignoring all VCS experience I have, "checkout" would indicate to me that I could "check something out" as in "have a peek at it."
    - Xurinos 16y ago
      In git, it means "checking out the current branch version of a file" or "checking out an entire branch". Pulling all the patches from another resource also makes sense. Think of checkout as a local thing to do, and pull/fetch as a remote action. It can make sense if you do not have prior associations. It is not as if the English language is not terribly abused and ambiguous in our languages. What does "cancel" mean? In linux with CUPS, it cancels a print job. To cancel a process, you have to kill it, but you cannot kill print jobs. Shocking. What is OOP? How does that definition change between C++, Java, Smalltalk, Lisp/CLOS, and vimscript? How about MVC? What about the differences in GUI lingo between Object Windows, McClim, Gtk, and qt? In other words, you have to learn the language of each different tool you use, and it is unreasonable to expect that it is the same as your other tools. Aside from that, it is terribly unfair to try to compare svn to git in any meaningful architectural sense; they are completely different creatures that accomplish some of the same goals. git does it better. And it uses different language to describe its new approach. I have not had a difficult time switching between using svn and git after using both for a long time, except for missing nice features like "git log -p" and "git add -p" when I work with svn. It seems petty to me to quibble over command names.

All the people suggesting various git commands he should be using are completely missing the point.

by Qz 16y ago

All the people suggesting various git commands he should be using are completely missing the point.

IsaacSchlueter 16y ago

The point being that the author isn't looking for solutions, but rather just wants to bitch?

Qz 16y ago
The point being that the solutions are problematic.
- itistoday 16y ago
  And the problems shouldn't exist in the first place.
  - MikeTaylor 16y ago
    But, yes, I do also like to bitch about them :-)
    - ableal 16y ago
      Watch out for the flying door-knobs. ( http://news.ycombinator.com/item?id=1272779 http://news.ycombinator.com/item?id=1272779 ) Seems that the peasants who have binaries should use rsync manually, instead of expecting tools to do the job.
  - donaq 16y ago
    Linus didn't write git for you. He wrote it for himself. Git works exactly the way Linus (and his merry band of kernel hackers (and others, who thought DVCS was a cool idea when they heard about it and were prepared to relearn SCM to use it)) wants it to work. If you want to learn to use it, cool, welcome to the party. If you aren't prepared to invest the time, that's cool too. But don't try it for like a day expecting it to be svn++ and then complain that it isn't. That's like a Windows user declaring that Linux sucks because it isn't Windows. It wasn't meant to be. Although, complaining about Ubuntu not doing things the way they "should" is more valid, since Ubuntu is targeted at everyone. :)
    - viraptor 16y ago
      Git is gaining a lot of attention lately. It's becoming "the dvcs" now. And that means, if you start using it for your project, you should consider what does it mean for contributors / users. If it creates an additional step where someone will say - "it will take me more time to learn, than creating the patch itself", you've lost. If many people start using git, we can start expecting things from git. It's just not about an abstract "you" anymore.
      - donaq 16y ago
        If many people start using git, we can start expecting things from git. Why? The author of a piece of software is under no obligation to satisfy the expectations of its incidental users, especially if he's not selling it to them.
        viraptor 16y ago
        If they get big enough... no they don't have an obligation, but the idea of many people depending on them should be enough. It's like MS had no obligation to satisfy expectations of IE5 users (not sold directly) - sure they didn't - but many got very annoyed because of that and because of the market share, we had internet-wide consequences for standard-compliant websites. Still - they had no obligation.
        donaq 16y ago
        That is just wrong on so many levels. Firstly, Microsoft marketed the hell out of IE. The bundling of IE with Windows was their way of getting people to use IE instead of Netscape Navigator. Since their stand (in court, no less!) was that IE was an integral part of Windows, which they sold to users, they did have an obligation to satisfy users' expectations of it. Did anyone force you to use git by bundling it with some other piece of software you were using? Nope. Secondly, in what crazy alternate universe can git, which is given to you free as in libre as well as beer, be compared with IE? If you think git sucks, but still want to use it for some crazy reason, go ahead and modify it to suit your needs. Lastly, I cannot imagine a world where anyone would be forced to have to cater for a VCS the way we have to for browsers. They're simply too different in function. It's not like you're in danger of being forced into the business of implementing a service supporting commits and checkouts for two different types of repositories on the same source files... unless you work at GitHub. Heh.

itistoday 16y ago

Thank you. I suspect these folks were OK with spending hours learning about their DVCS, but for most others, this just seems like unnecessary tedium and frustration, "When can I get back to worrying about the code?" Someone needs to make the Mac of a DVCS, i.e. one that doesn't require a 20+ page tutorial to figure out, is completely intuitive and "just works." I currently use Mercurial, and while I don't think it qualifies as the Mac of DVCS's, it seems to be working decently enough so far (for my simple purposes). I could learn git, but thanks to hg-git I'm hoping I won't have to.

avar 16y ago
Why yes, a lot of us are just fine spending "hours" learning something that we'll probably spend more than a few years using. Git's user interface isn't perfect, but you're not going to get the "Mac of DVCSs" either. There's a reason for the complexity, doing stuff like merging together the work of three people is inherently complex. You're not going to come up with some solution that allows the user to "just do it" without also destroying history.
- viraptor 16y ago
  > You're not going to come up with some solution that allows the user to "just do it" without also destroying history. Really? I've got state A and state B. I tell my DVCS to merge them into state C. After reviewing the automatically guessed changes and manually changing the things which could not be guessed, I commit C'. C' is successor to both A and B. What exactly has been lost / destroyed here?
  - ekiru 16y ago
    Nothing. Conveniently, git allows you to do exactly that. 1. Checkout B. 2. Merge A into B. 3. Git tells you there's a merge conflict and what to do to fix it: "Auto-merging foo CONFLICT (content): Merge conflict in foo Automatic merge failed; fix conflicts and then commit the result." 4. Edit foo and fix the conflict. 5. "git add foo" 6. Commit. What's the problem?

pyre 16y ago

The point -- as I understand it -- is that the author feels that a version control system should act like X. So he takes a random version control system, reads about it briefly, and then tries to use it assuming that it acts like X. The version control system doesn't act like X, which leads to problems for the author. Author writes a blog post about how random version control system sucks because it doesn't meet his assumptions.

Xurinos 16y ago
That is what I got out of it. A big clue was his "git commit filename". git is not svn. Is git's greatest sin really that it uses a few of the same words with different meanings from how they have been used in the past? Someone in another post mentioned revert. svn revert file == git checkout file, while git revert patches out a whole change. It actually makes sense if you forget about cvs and svn's version of the API. I saw the word "intuitive" thrown around... http://www.asktog.com/papers/raskinintuit.html http://www.asktog.com/papers/raskinintuit.html
- phaylon 16y ago
  You mean it actually makes sense if you forget the other VCS versions of that command, and know git's? Because ignoring all VCS experience I have, "checkout" would indicate to me that I could "check something out" as in "have a peek at it."
  - Xurinos 16y ago
    In git, it means "checking out the current branch version of a file" or "checking out an entire branch". Pulling all the patches from another resource also makes sense. Think of checkout as a local thing to do, and pull/fetch as a remote action. It can make sense if you do not have prior associations. It is not as if the English language is not terribly abused and ambiguous in our languages. What does "cancel" mean? In linux with CUPS, it cancels a print job. To cancel a process, you have to kill it, but you cannot kill print jobs. Shocking. What is OOP? How does that definition change between C++, Java, Smalltalk, Lisp/CLOS, and vimscript? How about MVC? What about the differences in GUI lingo between Object Windows, McClim, Gtk, and qt? In other words, you have to learn the language of each different tool you use, and it is unreasonable to expect that it is the same as your other tools. Aside from that, it is terribly unfair to try to compare svn to git in any meaningful architectural sense; they are completely different creatures that accomplish some of the same goals. git does it better. And it uses different language to describe its new approach. I have not had a difficult time switching between using svn and git after using both for a long time, except for missing nice features like "git log -p" and "git add -p" when I work with svn. It seems petty to me to quibble over command names.