4 ms·

No it doesn't.

johnbender 17y ago
I fully agree with the above poster and his sentiment.
davidw 17y ago
Why don't you try refuting some of his points? Or else he might come back with "does too!"... I'm not overly impressed with git in terms of it doing the right thing by default. The best options are often sort of hidden away under some option that you have to remember. svn is much simpler and nicer from this point of view in that I don't often have to use flags with it to do the basics. Perhaps the title could be rephrased as something like: "if git hopes to grow outside the world of early adopters, it probably needs a better interface", although that's not nearly as snappy... While we're at it... can anyone: * Comment on mercurial and bzr from this point of view? * Comment on TortoiseGit?
- jjames 17y ago
  * "checkout" is a destructive command Most VCSs have a destructive command. If one doesn't expect the destruction from the command, they will no doubt be perturbed. * You can’t merge upstream changes into your local, uncommitted modifications Commit. * Git’s merge conflict resolution workflow is unintuitive Subjective but I'm curious which VCS has an intuitive merge conflict resolution workflow. I assume this means that without previous experience with the VCS a developer can (immediately?) intuit the workflow. * Interface for working with the index almost universally confusing Three switches for a single command. If you want to operate in a business as usual DWIM manner you can just remember --hard. All that said, I do believe git reuses some commands in a semantically elastic way, sometimes to the confusion of new users.
  - davidw 17y ago
    > Most VCSs have a destructive command. And the name tips you off that you're about to do something destructive. Like svn's "revert". On the other hand, 'checkout' sounds fairly innocent to me. > intuitive merge conflict resolution workflow. IIRC, recent versions of svn walk you through it, asking which one you want to keep or letting you edit the file(s). I actually use git (the branches are really nice for some things), but I'm considering VC systems for office use, and I'm not quite so sure I'd stick my neck out and recommend git.
    - masklinn 17y ago
      > I actually use git (the branches are really nice for some things) FWIW Mercurial now has git-style branches (called bookmarks, hg's branches are different beasts)
- stonemetal 17y ago
  To me it reads like a why use mercurial instead of git piece.
  - itistoday 17y ago
    Same here, 'cept s/mercurial/bazaar/g. ;-)
    - dlsspy 17y ago
      bzr's UI confuses the hell out of me. I have friends who know it really well and I usually ask them how to do things that are simple in git. In some cases I just hear that they would rather not do that [thing that is important to me]. As far as I can tell, it's because the tool doesn't allow them to. It's all a matter of perspective.
      - davidw 17y ago
        What sorts of things, out of curiosity?
        dlsspy 17y ago
        I had a small change sitting in a branch for about a month and wanted to update. I didn't want to do a merge. I did find that someone had created a simple rebase plugin for bzr, though. That made things a lot easier. I tend to commit lots of incremental progress. I talked to a couple of bzr users who do the same. They insisted that it was important to their project to include these changes that definitely don't compile (e.g. "committing because I'm getting up to go to the bathroom"), etc... in the long-term history of the project because it can help them remember what they were thinking when they were writing the code. Personally, I do the similar, but I rebase -i before I push and squash and reorder most of that down into small, working chunks that most accurately reflect the real changes to the project. That is, it's a higher priority to me to say what happened than how it happened. I'm thoroughly uninterested in what the state of the codebase was when you came up with the idea to work on something, how many times you pulled upstream code down, how many times you went to the bathroom, etc... I just want to know when your change went in that affected the state of the project, and exactly what it did. Theoretically, a recursive merge message would tell me this. In practice, it does not, and the merge diffs don't necessarily show the change that affected the tree, but the delta that had to be applied to resolve conflicts on the merge. I used to be a gnu arch user, and as such, I used to find it of utmost important to record every minor file save in my permanent history. I've learned since then that it doesn't help me actually understand the project. Also, the use of sequence numbers (hg has the same problem) causes a lot of confusion. Humans seem to like the idea that there's an easy to understand sequence, but that's false on any project with more than one developer. Specifically I had this problem with "buildbot try" -- the default implementation does a working-tree diff against the same revno upstream (e.g. if "bzr version-info" says 571, then it uses "bzr diff" to create a patch and sends it upstream against 571). However, if I've committed locally (because...that's just the right thing to do), then it will find either than upstream doesn't have a 572, or it's a different 572. Enter "bzr revision-info -rsubmit:" which introduces network (took 7.49 seconds for me just now) and "bzr diff -rrevid:[long-string-i-can't-double-click].." I can't tell you all of the exact scenarios that were causing me confusion, but they came down to things like the above.

No it doesn't.

I fully agree with the above poster and his sentiment.

Why don't you try refuting some of his points? Or else he might come back with "does too!"... I'm not overly impressed with git in terms of it doing the right thing by default. The best options are often sort of hidden away under some option that you have to remember. svn is much simpler and nicer from this point of view in that I don't often have to use flags with it to do the basics. Perhaps the title could be rephrased as something like: "if git hopes to grow outside the world of early adopters, it probably needs a better interface", although that's not nearly as snappy... While we're at it... can anyone: * Comment on mercurial and bzr from this point of view? * Comment on TortoiseGit?

jjames 17y ago
* "checkout" is a destructive command Most VCSs have a destructive command. If one doesn't expect the destruction from the command, they will no doubt be perturbed. * You can’t merge upstream changes into your local, uncommitted modifications Commit. * Git’s merge conflict resolution workflow is unintuitive Subjective but I'm curious which VCS has an intuitive merge conflict resolution workflow. I assume this means that without previous experience with the VCS a developer can (immediately?) intuit the workflow. * Interface for working with the index almost universally confusing Three switches for a single command. If you want to operate in a business as usual DWIM manner you can just remember --hard. All that said, I do believe git reuses some commands in a semantically elastic way, sometimes to the confusion of new users.
- davidw 17y ago
  > Most VCSs have a destructive command. And the name tips you off that you're about to do something destructive. Like svn's "revert". On the other hand, 'checkout' sounds fairly innocent to me. > intuitive merge conflict resolution workflow. IIRC, recent versions of svn walk you through it, asking which one you want to keep or letting you edit the file(s). I actually use git (the branches are really nice for some things), but I'm considering VC systems for office use, and I'm not quite so sure I'd stick my neck out and recommend git.
  - masklinn 17y ago
    > I actually use git (the branches are really nice for some things) FWIW Mercurial now has git-style branches (called bookmarks, hg's branches are different beasts)
stonemetal 17y ago
To me it reads like a why use mercurial instead of git piece.
- itistoday 17y ago
  Same here, 'cept s/mercurial/bazaar/g. ;-)
  - dlsspy 17y ago
    bzr's UI confuses the hell out of me. I have friends who know it really well and I usually ask them how to do things that are simple in git. In some cases I just hear that they would rather not do that [thing that is important to me]. As far as I can tell, it's because the tool doesn't allow them to. It's all a matter of perspective.
    - davidw 17y ago
      What sorts of things, out of curiosity?
      - dlsspy 17y ago
        I had a small change sitting in a branch for about a month and wanted to update. I didn't want to do a merge. I did find that someone had created a simple rebase plugin for bzr, though. That made things a lot easier. I tend to commit lots of incremental progress. I talked to a couple of bzr users who do the same. They insisted that it was important to their project to include these changes that definitely don't compile (e.g. "committing because I'm getting up to go to the bathroom"), etc... in the long-term history of the project because it can help them remember what they were thinking when they were writing the code. Personally, I do the similar, but I rebase -i before I push and squash and reorder most of that down into small, working chunks that most accurately reflect the real changes to the project. That is, it's a higher priority to me to say what happened than how it happened. I'm thoroughly uninterested in what the state of the codebase was when you came up with the idea to work on something, how many times you pulled upstream code down, how many times you went to the bathroom, etc... I just want to know when your change went in that affected the state of the project, and exactly what it did. Theoretically, a recursive merge message would tell me this. In practice, it does not, and the merge diffs don't necessarily show the change that affected the tree, but the delta that had to be applied to resolve conflicts on the merge. I used to be a gnu arch user, and as such, I used to find it of utmost important to record every minor file save in my permanent history. I've learned since then that it doesn't help me actually understand the project. Also, the use of sequence numbers (hg has the same problem) causes a lot of confusion. Humans seem to like the idea that there's an easy to understand sequence, but that's false on any project with more than one developer. Specifically I had this problem with "buildbot try" -- the default implementation does a working-tree diff against the same revno upstream (e.g. if "bzr version-info" says 571, then it uses "bzr diff" to create a patch and sends it upstream against 571). However, if I've committed locally (because...that's just the right thing to do), then it will find either than upstream doesn't have a 572, or it's a different 572. Enter "bzr revision-info -rsubmit:" which introduces network (took 7.49 seconds for me just now) and "bzr diff -rrevid:[long-string-i-can't-double-click].." I can't tell you all of the exact scenarios that were causing me confusion, but they came down to things like the above.