3 ms·

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 frustr

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?
    - viraptor 16y ago
      Parent claimed that it cannot be done, I responded. Not sure what is the problem...
    - phaylon 16y ago
      But you're not committing, you're adding.
  - avar 16y ago
    My post was unfortunately worded. That's what you get for posting late at night I guess. What I meant to say is that you're not going to get away with using any sort of complex system without understanding what it's doing. This seems to be the sentiment expressed in the original posting, and some of the replies here. Sure, Git's UI could be improved. But managing several divergent histories and correctly merging them together is a non-trivial problem. If you make a tool that allows the user to just plow on without understanding the underlying paradigm the results are going to suffer. It's like asking for a RDBMS that allows you to "just do it". You might get away with that for a while, but not for long.
- itistoday 16y ago
  > 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. This is a limitation of your imagination. You can write a DVCS that's easy to use and intuitive. Git has an absolutely terrible UI, it borders on idiotic. One example of a DVCS with a good design and UI is a Bazaar. Sortof like the Mac a few years ago, no one uses it, but I wouldn't be surprised if it eventually gains in popularity. I see two things holding it back right now: - Launchpad is terrible and needs to be at least as good as Github. - In concert with having a terrible "hub", Bazaar has a small community of users. To gain users, it will need to out-innovate like Apple did. That means on all fronts, not just bzr itself but the community, marketing, and the websites that support it.
  - pyre 16y ago
    Issues that I've heard of with Bazaar: - Being pure Python it doesn't have the same performance that git does. This may not show up in day-to-day usage, but things like 'convert this svn repo to Bazaar' tend to bring the bottlenecks/performance issues into the light. - Bazaar made this weird design decision to have two revision numbers. a 'r12345' type revision number that is similar to SVN, but only applies to your local checkout of the repo, and a checksum (SHA1 or MD5) which applies globally (across different checkouts). I think that choosing a revision scheme similar to SVN's but one that doesn't map 1-to-1 with SVN is just asking for confusion from newbies. (I'm not entirely sure why one needs to have local and global revision numbers...)
    - lars512 16y ago
      The use case for numeric local revisions is pretty clear. How many global operations do you really do? In reality, nearly all operations are local. So would you rather write r37 or 0b090d7267df? Why wouldn't you want the choice?
      - pyre 16y ago
        Two points: 1. You can abbreviate the SHA-1's in git 2. When you are collaborating on code, it's much more common to use a global identifier so that people can all know which commit is being referenced. It seems like you are making things needlessly complex when you are trying to maintain local and global revision numbers, for little (in my opinion) return. Sure 'r37' is easier to remember off-hand than '5b98d8f' (a shortened SHA1), but if you memorize 'r37' it only means something locally, you'll still have to lookup the global revision id when you want to communicate with others.

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?
  - viraptor 16y ago
    Parent claimed that it cannot be done, I responded. Not sure what is the problem...
  - phaylon 16y ago
    But you're not committing, you're adding.
- avar 16y ago
  My post was unfortunately worded. That's what you get for posting late at night I guess. What I meant to say is that you're not going to get away with using any sort of complex system without understanding what it's doing. This seems to be the sentiment expressed in the original posting, and some of the replies here. Sure, Git's UI could be improved. But managing several divergent histories and correctly merging them together is a non-trivial problem. If you make a tool that allows the user to just plow on without understanding the underlying paradigm the results are going to suffer. It's like asking for a RDBMS that allows you to "just do it". You might get away with that for a while, but not for long.
itistoday 16y ago
> 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. This is a limitation of your imagination. You can write a DVCS that's easy to use and intuitive. Git has an absolutely terrible UI, it borders on idiotic. One example of a DVCS with a good design and UI is a Bazaar. Sortof like the Mac a few years ago, no one uses it, but I wouldn't be surprised if it eventually gains in popularity. I see two things holding it back right now: - Launchpad is terrible and needs to be at least as good as Github. - In concert with having a terrible "hub", Bazaar has a small community of users. To gain users, it will need to out-innovate like Apple did. That means on all fronts, not just bzr itself but the community, marketing, and the websites that support it.
- pyre 16y ago
  Issues that I've heard of with Bazaar: - Being pure Python it doesn't have the same performance that git does. This may not show up in day-to-day usage, but things like 'convert this svn repo to Bazaar' tend to bring the bottlenecks/performance issues into the light. - Bazaar made this weird design decision to have two revision numbers. a 'r12345' type revision number that is similar to SVN, but only applies to your local checkout of the repo, and a checksum (SHA1 or MD5) which applies globally (across different checkouts). I think that choosing a revision scheme similar to SVN's but one that doesn't map 1-to-1 with SVN is just asking for confusion from newbies. (I'm not entirely sure why one needs to have local and global revision numbers...)
  - lars512 16y ago
    The use case for numeric local revisions is pretty clear. How many global operations do you really do? In reality, nearly all operations are local. So would you rather write r37 or 0b090d7267df? Why wouldn't you want the choice?
    - pyre 16y ago
      Two points: 1. You can abbreviate the SHA-1's in git 2. When you are collaborating on code, it's much more common to use a global identifier so that people can all know which commit is being referenced. It seems like you are making things needlessly complex when you are trying to maintain local and global revision numbers, for little (in my opinion) return. Sure 'r37' is easier to remember off-hand than '5b98d8f' (a shortened SHA1), but if you memorize 'r37' it only means something locally, you'll still have to lookup the global revision id when you want to communicate with others.