7 ms·

What git is not

52 points by qrush 18y ago

100k 18y ago
The reason I think git is complicated isn't because it's complicated conceptually. It's because the commands are intentionally different from other SCMs, which is highly annoying when you know what you want to do but can't figure it out. For example, how do you revert a file in your working directory? Oh, git checkout HEAD file -- obviously!
- jrockway 18y ago
  You seem to think that other version control systems don't have this problem. Let's consider subversion. Let's say you want to revert commit 1234. You just say "svn revert 1234", right? No. svn revert does something completely unrelated. In git, "git revert 1234" does revert changeset 1234. So you see, you actually have to learn about the version control system, regardless of which you choose. You can't just make stuff up and expect the computer to understand what you mean.
  - 100k 18y ago
    Agreed! But I already know SVN, and Linus intentionally made git different than the other SCMs because he thinks they suck. I think that's annoying. And there's no way you can tell me that the git command set is more discoverable than, say, Mercruial's. Many common, every day commands in git are very difficult to figure out without a lot of searching and reading. This is not true with Mercurial.
    - nuclear_eclipse 18y ago
      Between `git help -a` to see all the available commands, and `git help <command>` or `man git-<command>`, I don't see how Git is any worse than any other VCS tool. Git is extremely well-documented, and even goes so far as to provide ASCII-diagrams in the docs to help you visualize what certain commands do. Or are you just being picky because Git doesn't name everything exactly the same as other tools do?
      - 100k 18y ago
        I think it would be better if git had decided to model its commands on Subversion, yes. However, I am mostly complaining because certain very common operations are way more complicated than they need to be.
        nuclear_eclipse 18y ago
        What are your specific complaints, and are they anything more than the age-old "`git commit` doesn't commit everything by default"? I'm not trying to snark; I'm genuinely interested in what people find difficult about Git, that much more it's possible to "fix". If there's something complex that you think should be easy, you always have two basic options: - create an alias in your ~/.gitconfig linking a short command name to a long command/argument sequence - create a shell script in /usr/libexec/git-core (or the equivalent) that does what you want, and you can instantly use that in the standard `git <command>` method. For an example, I have aliased 'co' to 'checkout', 'ci' to 'commit -a', 'pullr' to 'pull --rebase', and 'fp' to 'format-patch --binary'.
      - davidw 18y ago
        I started with cvs, years ago, moved on to subversion when it was good and stable, and am now starting to fiddle with git. I like it a lot, but it is "fiddly" feeling. I'm sorry I can't describe it better than that, but it's just a feeling I get from it. Maybe this covers it: I don't get the feeling that it's going to much effort to "make the easy things simple and the hard things possible". We know it can do the latter, but the former is not always true.
        jrockway 18y ago
        "make the easy things simple and the hard things possible" Well, it's Git, not Perl :) I like it a lot, but it is "fiddly" feeling. To assuage this feeling, I recommend reading the source code for both Git and Subversion. After you realize the flaky shoestring-and-chewing-gum model that holds all your data in subversion, you won't worry at all about Git's UI :)
        18y ago
- lnguyen 18y ago
  All SCM tools will frustrate anyone migrating from one to another. I've done migrations among most of the major commercial SCM tools and had to write training documentation for developers. You do have to realize that if the underlying model for version control is different, then commands and terms will be different even if they share the same name like "checkout." And what you think you can or want to do might not be what you really should do. So expect some initial frustrations and a lot of referencing of the man pages, documentation, blogs. You're going to have to unlearn a lot of behaviors that may be second nature to you. But at the end, you'll get a much better appreciation of what each tool gets right and an understanding of their limitations.
pstinnett 18y ago
For someone who doesn't have much experience with SCMs, is it worth learning Git or should I learn SVN? I get the general idea behind both - just not sure what I should dive into.
- bisceglie 18y ago
  learn both. get comfortable with both. i don't see SVN being abandoned, and a lot of companies/projects use it. i like GIT over SVN, but am glad i'm comfortable with both.
- arebop 18y ago
  Contrary to what seems like the prevailing view right now, Git is not strictly better than SVN. Some reasons to use SVN are at http://blog.red-bean.com/sussman/?p=90 http://blog.red-bean.com/sussman/?p=90. It sounds like you want to use SCM in a personal (not collaborative) capacity. I think both SVN and Git are suitable for this purpose, but maybe Git has the edge because its philosophy doesn't privilege a repository.
  - old-gregg 18y ago
    I believe Git is strictly better than SVN even for one-person-never-share style of development simply because of much, much, much better branching/merging. Being able to maintain and merge multiple branches without any effort is a huge, in my opinion. I don't think you can get away without using at lest some branching features in any project: at the minimum you'd need to maintain tags for released versions and keep "latest stable" from "development/experimental" code separated. And this is where Git shines. I'm not saying SVN can't do branches or tags, I'm saying it takes more effort, and tools in general are supposed to make hard things easy.
    - davidw 18y ago
      I'd say git is better for that situation because it's so simple to set up. That's one thing it really does well. Tons of branches and other stuff are likely to be less of an issue on small, personal, non-shared projects.
budwin 18y ago
i detect bias :)
glazz 18y ago
And what about bazaar? Is it better or worse than git?
- Harkins 18y ago
  Both. (Your question is too broad.)
jodrellblank 18y ago
Just to reference another HN discussion "My web is text based" (here http://news.ycombinator.com/item?id=488030 http://news.ycombinator.com/item?id=488030 ) - this is the sort of topic where I think video and screencasts would be helpful. Not a screencast of someone typing DVCS commands into a shell, mind you, or a video of someone talking about DVCS that could be transcribed to text with no loss of explanatory power whatsoever, or, $deity forbid, a video of someone reading inaudibly from illegible slides. A decent animated introduction to distributed version control explained by characters worthy of Pixar, set in a world of fantasy physics where things can pop into and out of existance. DVCSs do things which are non linear, text and talk are extremely linear. Text and audio shouldn't be the only two forms of media on the web, video explanation shouldn't mean linear explanation.
- MartinMond 18y ago
  There's http://gitcasts.com/posts/railsconf-git-talk http://gitcasts.com/posts/railsconf-git-talk It helped me to actually get git (incidentally that's also the talk's title). Don't let the "rails" in the URL mislead you, it's mostly about git and you can easily skip the part about Rails.
njharman 18y ago
These always (fail to)address the same old issues. I switched to SVN for some specific features. I've looked and not been able to get definite answers if git supports these. In fact I've mostly gotten "if you don't do it/use it our way you're stupid, go away". proper directory move/rename history proper binary handling(that is no merging, newest file wins) proper line ending handling (that is default to convert to local system's standard but overrideable per file/file pattern) proper permission handling (track permissions and set them on check out/update/whatever you call it) git seems focused solely on source code and heavily towards the Linux Kernel development process. I use svn for website deployments, tracking changes to servers' filesystems(parts thereof), and occasional source code. I don't use anything close to the Linux Kernel dev process.
- Harkins 18y ago
  I think in this case the word "proper" means "the way that seems intuitive to me". This is not bad, but other people have made different technical decisions. Adding the word "proper" tries to make these into quality judgments into opinions, but that's still what they are. I hope you find a system that works as you prefer.
  - njharman 18y ago
    Yes I agree. I meant and hoped that the (explanation in parens) would be interpreted as my opinion on what was proper. Believed the construct "proper ... (that is ...)" was clear, guess not. Oh, and thanks for not answering any of my questions and ranting off topic. [an aside; I don't believe in "proper", there is no proper there is only "proper for me", never "proper for you." One should reject others' attempts to inflict "what is proper" on them. Good job btw. My use was to alter people's thinking or simply make them think, even subconsciously. Language is a virus.]
DannoHung 18y ago
The only thing I worry about with git is getting really raw developers who have never, ever used version control up and running in a semblance of a reasonable manner of operation. I mean, I know people who were resistant to using subversion because they didn't understand how it was supposed to work. I sort of shudder to think about the mental reaction to being dropped into git. Because of this I originally supported Darcs. I still would if they could clean up some of the patch resolution problems that they have and the Darcs GitHub-like got halfway decent (maybe with Camp). Source Control is one of the fundamental tenets of development and getting newbs trained on it is so incredibly important. We, collectively, can't afford for it to be a tough thing to get a handle on. Even if it takes time to really understand, it needs to be easy to get going and using the tool in a good semblance of the proper manner.

52 points by qrush 18y ago

100k 18y ago

The reason I think git is complicated isn't because it's complicated conceptually. It's because the commands are intentionally different from other SCMs, which is highly annoying when you know what you want to do but can't figure it out. For example, how do you revert a file in your working directory? Oh, git checkout HEAD file -- obviously!

jrockway 18y ago
You seem to think that other version control systems don't have this problem. Let's consider subversion. Let's say you want to revert commit 1234. You just say "svn revert 1234", right? No. svn revert does something completely unrelated. In git, "git revert 1234" does revert changeset 1234. So you see, you actually have to learn about the version control system, regardless of which you choose. You can't just make stuff up and expect the computer to understand what you mean.
- 100k 18y ago
  Agreed! But I already know SVN, and Linus intentionally made git different than the other SCMs because he thinks they suck. I think that's annoying. And there's no way you can tell me that the git command set is more discoverable than, say, Mercruial's. Many common, every day commands in git are very difficult to figure out without a lot of searching and reading. This is not true with Mercurial.
  - nuclear_eclipse 18y ago
    Between `git help -a` to see all the available commands, and `git help <command>` or `man git-<command>`, I don't see how Git is any worse than any other VCS tool. Git is extremely well-documented, and even goes so far as to provide ASCII-diagrams in the docs to help you visualize what certain commands do. Or are you just being picky because Git doesn't name everything exactly the same as other tools do?
    - 100k 18y ago
      I think it would be better if git had decided to model its commands on Subversion, yes. However, I am mostly complaining because certain very common operations are way more complicated than they need to be.
      - nuclear_eclipse 18y ago
        What are your specific complaints, and are they anything more than the age-old "`git commit` doesn't commit everything by default"? I'm not trying to snark; I'm genuinely interested in what people find difficult about Git, that much more it's possible to "fix". If there's something complex that you think should be easy, you always have two basic options: - create an alias in your ~/.gitconfig linking a short command name to a long command/argument sequence - create a shell script in /usr/libexec/git-core (or the equivalent) that does what you want, and you can instantly use that in the standard `git <command>` method. For an example, I have aliased 'co' to 'checkout', 'ci' to 'commit -a', 'pullr' to 'pull --rebase', and 'fp' to 'format-patch --binary'.
    - davidw 18y ago
      I started with cvs, years ago, moved on to subversion when it was good and stable, and am now starting to fiddle with git. I like it a lot, but it is "fiddly" feeling. I'm sorry I can't describe it better than that, but it's just a feeling I get from it. Maybe this covers it: I don't get the feeling that it's going to much effort to "make the easy things simple and the hard things possible". We know it can do the latter, but the former is not always true.
      - jrockway 18y ago
        "make the easy things simple and the hard things possible" Well, it's Git, not Perl :) I like it a lot, but it is "fiddly" feeling. To assuage this feeling, I recommend reading the source code for both Git and Subversion. After you realize the flaky shoestring-and-chewing-gum model that holds all your data in subversion, you won't worry at all about Git's UI :)
      - 18y ago
lnguyen 18y ago
All SCM tools will frustrate anyone migrating from one to another. I've done migrations among most of the major commercial SCM tools and had to write training documentation for developers. You do have to realize that if the underlying model for version control is different, then commands and terms will be different even if they share the same name like "checkout." And what you think you can or want to do might not be what you really should do. So expect some initial frustrations and a lot of referencing of the man pages, documentation, blogs. You're going to have to unlearn a lot of behaviors that may be second nature to you. But at the end, you'll get a much better appreciation of what each tool gets right and an understanding of their limitations.

pstinnett 18y ago

For someone who doesn't have much experience with SCMs, is it worth learning Git or should I learn SVN? I get the general idea behind both - just not sure what I should dive into.

bisceglie 18y ago
learn both. get comfortable with both. i don't see SVN being abandoned, and a lot of companies/projects use it. i like GIT over SVN, but am glad i'm comfortable with both.
arebop 18y ago
Contrary to what seems like the prevailing view right now, Git is not strictly better than SVN. Some reasons to use SVN are at http://blog.red-bean.com/sussman/?p=90 http://blog.red-bean.com/sussman/?p=90. It sounds like you want to use SCM in a personal (not collaborative) capacity. I think both SVN and Git are suitable for this purpose, but maybe Git has the edge because its philosophy doesn't privilege a repository.
- old-gregg 18y ago
  I believe Git is strictly better than SVN even for one-person-never-share style of development simply because of much, much, much better branching/merging. Being able to maintain and merge multiple branches without any effort is a huge, in my opinion. I don't think you can get away without using at lest some branching features in any project: at the minimum you'd need to maintain tags for released versions and keep "latest stable" from "development/experimental" code separated. And this is where Git shines. I'm not saying SVN can't do branches or tags, I'm saying it takes more effort, and tools in general are supposed to make hard things easy.
  - davidw 18y ago
    I'd say git is better for that situation because it's so simple to set up. That's one thing it really does well. Tons of branches and other stuff are likely to be less of an issue on small, personal, non-shared projects.

budwin 18y ago

i detect bias :)

glazz 18y ago

And what about bazaar? Is it better or worse than git?

Harkins 18y ago
Both. (Your question is too broad.)

jodrellblank 18y ago

Just to reference another HN discussion "My web is text based" (here http://news.ycombinator.com/item?id=488030 http://news.ycombinator.com/item?id=488030 ) - this is the sort of topic where I think video and screencasts would be helpful. Not a screencast of someone typing DVCS commands into a shell, mind you, or a video of someone talking about DVCS that could be transcribed to text with no loss of explanatory power whatsoever, or, $deity forbid, a video of someone reading inaudibly from illegible slides. A decent animated introduction to distributed version control explained by characters worthy of Pixar, set in a world of fantasy physics where things can pop into and out of existance. DVCSs do things which are non linear, text and talk are extremely linear. Text and audio shouldn't be the only two forms of media on the web, video explanation shouldn't mean linear explanation.

MartinMond 18y ago
There's http://gitcasts.com/posts/railsconf-git-talk http://gitcasts.com/posts/railsconf-git-talk It helped me to actually get git (incidentally that's also the talk's title). Don't let the "rails" in the URL mislead you, it's mostly about git and you can easily skip the part about Rails.

njharman 18y ago

These always (fail to)address the same old issues. I switched to SVN for some specific features. I've looked and not been able to get definite answers if git supports these. In fact I've mostly gotten "if you don't do it/use it our way you're stupid, go away". proper directory move/rename history proper binary handling(that is no merging, newest file wins) proper line ending handling (that is default to convert to local system's standard but overrideable per file/file pattern) proper permission handling (track permissions and set them on check out/update/whatever you call it) git seems focused solely on source code and heavily towards the Linux Kernel development process. I use svn for website deployments, tracking changes to servers' filesystems(parts thereof), and occasional source code. I don't use anything close to the Linux Kernel dev process.

Harkins 18y ago
I think in this case the word "proper" means "the way that seems intuitive to me". This is not bad, but other people have made different technical decisions. Adding the word "proper" tries to make these into quality judgments into opinions, but that's still what they are. I hope you find a system that works as you prefer.
- njharman 18y ago
  Yes I agree. I meant and hoped that the (explanation in parens) would be interpreted as my opinion on what was proper. Believed the construct "proper ... (that is ...)" was clear, guess not. Oh, and thanks for not answering any of my questions and ranting off topic. [an aside; I don't believe in "proper", there is no proper there is only "proper for me", never "proper for you." One should reject others' attempts to inflict "what is proper" on them. Good job btw. My use was to alter people's thinking or simply make them think, even subconsciously. Language is a virus.]

DannoHung 18y ago

The only thing I worry about with git is getting really raw developers who have never, ever used version control up and running in a semblance of a reasonable manner of operation. I mean, I know people who were resistant to using subversion because they didn't understand how it was supposed to work. I sort of shudder to think about the mental reaction to being dropped into git. Because of this I originally supported Darcs. I still would if they could clean up some of the patch resolution problems that they have and the Darcs GitHub-like got halfway decent (maybe with Camp). Source Control is one of the fundamental tenets of development and getting newbs trained on it is so incredibly important. We, collectively, can't afford for it to be a tough thing to get a handle on. Even if it takes time to really understand, it needs to be easy to get going and using the tool in a good semblance of the proper manner.