3 ms·

Maybe it's because Git was my first VCS, but I find SVN extremely frustrating to use at work. I'm having troubles understanding the examples you gave, though. I

Maybe it's because Git was my first VCS, but I find SVN extremely frustrating to use at work. I'm having troubles understanding the examples you gave, though. Is coming up with (presumably topic) branch names really that hard? Just name it "foo" or "woot" temporarily until you have the energy to come up with a more-friendly one. What do you mean by "Why wouldn't I just sync a repository completely?" Is this supposed to mean that the concept of private, local branches is confusing? And "Why not just clone the whole repository?" really baffles me, because that's exactly what cloning already does...

bsder 12y ago
> Just name it "foo" or "woot" temporarily until you have the energy to come up with a more-friendly one. But how do I merge your "foo" and my "woot"? Um ... why should I even have to care? Why aren't we just working on the same branch by default? > Is this supposed to mean that the concept of private, local branches is confusing? Yes. What happens when I type "git push"? Which of my named branches got transferred? Um ... > "Why not just clone the whole repository?" really baffles me, because that's exactly what cloning already does... So, is that before or after having been gc'd? Which branches did you get? etc. If there are 3 people generating code artifacts in an office, one of which is an artist, I DON'T CARE about any of these things. Worse, they are wasted mental energy for people who don't like this kind of stuff (the artist, for example, likely doesn't enjoy graph theory). Worst, they are ways that you can corrupt your repository or blow your code away. The fact that I have to think about graph theory to use a DVCS in daily use is unacceptable. It means I can't explain this to writers, artists, and other non-programmers who I would really like to have in source control, too. I explain mercurial vs git like the difference between a high-end chainsaw and a logging chainsaw. A high-end chainsaw has things like safeties, a blade clutch, electric starters, comfortable handles, etc. It will go through 99% of the trees anybody will use it for. A logging chainsaw doesn't have lots of amenities, but the motor is bigger and it will blow through 100% of trees. It's also a hell of a lot heavier which means it's harder to control and more likely to seriously hurt you when something goes wrong.
- kinghajj 12y ago
  > But how do I merge your "foo" and my "woot"? `git checkout woot; git merge his/foo`? > Um ... why should I even have to care? Because it helps encourage separating work logically, and gives you quick way to reset your working tree to a known state should merging upstream changes go awry? > Why aren't we just working on the same branch by default? You are, you just create topic branches off the development one to focus a series of commits on some goal. When you're ready to share it, just merge it into the development branch and push it. If you and your colleague are working on a topic together, you do the same, just push to some common remote branch for that topic. > What happens when I type "git push"? In Git 2.0, it pushes the current branch iff it tracks a remote upstream one; otherwise it prints an error explaining how to set the upstream branch for the current branch. > So, is that before or after having been gc'd? GCing only removes garbage. Since you're creating branches to keep track of your topics, this shouldn't ever be a problem. If you had no references to a commit, it must not have been important! > Which branches did you get? etc. As far as I know, cloning gets every branch from a remote; not all branches will automatically have tracking branches, but making those is easy enough. > Worst, they are ways that you can corrupt your repository or blow your code away. Do you mean making incompatible commits via rebasing by "corruption," or are you referring to actual repository data loss due to bugs? I'm unaware of the latter. If you consistently make temporary private branches, it should be impossible to lose work. Is graph theory really that complicated? I always thought it was one of the more intuitive compsci topics, since it's very visual. Maybe that's my bias, though. I try Mercurial every once in a while, so I'm not basing my opinion only on old versions (in fact, I just played around with it again today.) I always feel constrained--like it's trying to prevent me from doing what I want to do. A lot of it is familiarity, I'm sure, and differences in nomenclature (though, I'll say, "checkout" makes a lot more sense than "update" to me--I would assume that "update" would be analogous to "fetch").
  - bsder 12y ago
    > actual repository data loss due to bugs? Not bugs. Actual repository loss due to commands functioning as intended. "git push" tends to be the culprit. I have seen more people blast repositories with it than you would believe. > Is graph theory really that complicated? I always thought it was one of the more intuitive compsci topics, since it's very visual. Maybe that's my bias, though. Repeat after me: "Not everybody is a programmer." Okay? Really. I want my artists, composers, writers, etc. to put their stuff in version control. They can't do that if a third or fourth year course in CS is a prerequisite. And that's my biggest counterpoint. I can and have taught people who have basic computer literacy how to use CVS, svn, hg, and even bzr. git is completely opaque to those same people.

bsder 12y ago

> Just name it "foo" or "woot" temporarily until you have the energy to come up with a more-friendly one. But how do I merge your "foo" and my "woot"? Um ... why should I even have to care? Why aren't we just working on the same branch by default? > Is this supposed to mean that the concept of private, local branches is confusing? Yes. What happens when I type "git push"? Which of my named branches got transferred? Um ... > "Why not just clone the whole repository?" really baffles me, because that's exactly what cloning already does... So, is that before or after having been gc'd? Which branches did you get? etc. If there are 3 people generating code artifacts in an office, one of which is an artist, I DON'T CARE about any of these things. Worse, they are wasted mental energy for people who don't like this kind of stuff (the artist, for example, likely doesn't enjoy graph theory). Worst, they are ways that you can corrupt your repository or blow your code away. The fact that I have to think about graph theory to use a DVCS in daily use is unacceptable. It means I can't explain this to writers, artists, and other non-programmers who I would really like to have in source control, too. I explain mercurial vs git like the difference between a high-end chainsaw and a logging chainsaw. A high-end chainsaw has things like safeties, a blade clutch, electric starters, comfortable handles, etc. It will go through 99% of the trees anybody will use it for. A logging chainsaw doesn't have lots of amenities, but the motor is bigger and it will blow through 100% of trees. It's also a hell of a lot heavier which means it's harder to control and more likely to seriously hurt you when something goes wrong.

kinghajj 12y ago
> But how do I merge your "foo" and my "woot"? `git checkout woot; git merge his/foo`? > Um ... why should I even have to care? Because it helps encourage separating work logically, and gives you quick way to reset your working tree to a known state should merging upstream changes go awry? > Why aren't we just working on the same branch by default? You are, you just create topic branches off the development one to focus a series of commits on some goal. When you're ready to share it, just merge it into the development branch and push it. If you and your colleague are working on a topic together, you do the same, just push to some common remote branch for that topic. > What happens when I type "git push"? In Git 2.0, it pushes the current branch iff it tracks a remote upstream one; otherwise it prints an error explaining how to set the upstream branch for the current branch. > So, is that before or after having been gc'd? GCing only removes garbage. Since you're creating branches to keep track of your topics, this shouldn't ever be a problem. If you had no references to a commit, it must not have been important! > Which branches did you get? etc. As far as I know, cloning gets every branch from a remote; not all branches will automatically have tracking branches, but making those is easy enough. > Worst, they are ways that you can corrupt your repository or blow your code away. Do you mean making incompatible commits via rebasing by "corruption," or are you referring to actual repository data loss due to bugs? I'm unaware of the latter. If you consistently make temporary private branches, it should be impossible to lose work. Is graph theory really that complicated? I always thought it was one of the more intuitive compsci topics, since it's very visual. Maybe that's my bias, though. I try Mercurial every once in a while, so I'm not basing my opinion only on old versions (in fact, I just played around with it again today.) I always feel constrained--like it's trying to prevent me from doing what I want to do. A lot of it is familiarity, I'm sure, and differences in nomenclature (though, I'll say, "checkout" makes a lot more sense than "update" to me--I would assume that "update" would be analogous to "fetch").
- bsder 12y ago
  > actual repository data loss due to bugs? Not bugs. Actual repository loss due to commands functioning as intended. "git push" tends to be the culprit. I have seen more people blast repositories with it than you would believe. > Is graph theory really that complicated? I always thought it was one of the more intuitive compsci topics, since it's very visual. Maybe that's my bias, though. Repeat after me: "Not everybody is a programmer." Okay? Really. I want my artists, composers, writers, etc. to put their stuff in version control. They can't do that if a third or fourth year course in CS is a prerequisite. And that's my biggest counterpoint. I can and have taught people who have basic computer literacy how to use CVS, svn, hg, and even bzr. git is completely opaque to those same people.