4 ms·

> I think Git turned out to have the better UI [...] I think I have never heard that from anybody versed in git and any other distributed source control manage

by bch 7y ago

> I think Git turned out to have the better UI [...] I think I have never heard that from anybody versed in git and any other distributed source control manager. Architecturally, we can look at (eg) speed performance and reasonable people could agree git leads or is a competitive contender. What UI examples is git bringing though? I’d love to love it, but to me it feels like a UI/UX disaster, and “getting used to it” is NOT an excuse when we have mercurial or fossil showing how much better it can be.

amluto 7y ago
I like git’s architecture better — hg’s exposure of revision numbers needlessly tangles branches together and makes anything that creates throwaway commits messy. But git’s user experience is IMO gratuitously awful. Trying to keep track of all the various things that checkout and reset do leads mainly to frustration at the design. And I see no reason that use of the index should ever be required.
- WorldMaker 7y ago
  Good news, in the latest git release checkout has two new friends that split checkout's functionality: switch and restore. Plus, they have much friendlier flags for knowing if they are affecting the index, the working tree, or both.
chrisseaton 7y ago
Things like interactive rebase in Git are revision control UI innovations with a massive impact on my ability to deliver quality PRs. Git feels like a tool I can use to create and mould meaningful commits that best convey intent. Mercurial feels like it wants to just make a literal log of what I've done, which is a bit simplistic and isn't the same as what I want to present when my code is ready. I also find the model of Git much easier to understand and explain to others.
- pseudalopex 7y ago
  Mercurial copied interactive rebase from Git a long time ago and refined it with phases[1]. What do you find easier to understand and explain about Git's model? [1] https://www.mercurial-scm.org/wiki/Phases https://www.mercurial-scm.org/wiki/Phases
  - chrisseaton 7y ago
    Yeah they copied it. They copied it because it was better. Do you think that they copied it because it was a bad UI idea? Not sure what your point is. And great question about the Git model, after mentioning 'phases'! Mercurial has about a billion concepts and nouns for different random things like that. It takes forever to explain all the random ideas they've piled into it in an attempt to keep up with Git. Mercurial think they can fix everything with yet another plugin and new concepts and nouns. Git built a cleaner model where you don’t need these plugins and abstractions.
    - pseudalopex 7y ago
      How does Mercurial feel like "it wants to just make a literal log of what I've done"? It has a UI very similar to Git's for rewriting history and a feature specifically to help do it safely. Git copied things from Mercurial too. I don't think Git having a feature Mercurial didn't in 2007 means "Git turned out to have the better UI and architecture". Git still has the problem Mercurial phases address. A lot of Git users are annoyed that Mercurial branches work like other systems instead of Git and that it calls Git branches "bookmarks". New users understand Mercurial branches much more easily in my experience. Mercurial queues are complex but only needed for workflows Git doesn't support. They're an extension so that most people don't even need to know they exist. Do you have any other examples?
      - chrisseaton 7y ago
        > How does Mercurial feel like "it wants to just make a literal log of what I've done"? Because rebasing was literally an afterthought - a plugin. I don't think I ever push commits without rebasing them a few times. There's also now about six different ways to rewrite your history in Mercurial. It's a mess. Git has one way to do it and it's a normal part of the system. If a Mercurial user asks me how to tidy up their history my answer is 'er... well there's rebase, mq, histedit, evolve...' that's a lot of options to teach people. In Git I just show them rebase. It's all subjective isn't it? For me, less concepts, nouns, and plugins adds up to a simpler and so better architecture and UI. Maybe the extra concepts are what floats your boat and that's fine.

by bch 7y ago

amluto 7y ago

I like git’s architecture better — hg’s exposure of revision numbers needlessly tangles branches together and makes anything that creates throwaway commits messy. But git’s user experience is IMO gratuitously awful. Trying to keep track of all the various things that checkout and reset do leads mainly to frustration at the design. And I see no reason that use of the index should ever be required.

WorldMaker 7y ago
Good news, in the latest git release checkout has two new friends that split checkout's functionality: switch and restore. Plus, they have much friendlier flags for knowing if they are affecting the index, the working tree, or both.

chrisseaton 7y ago

Things like interactive rebase in Git are revision control UI innovations with a massive impact on my ability to deliver quality PRs. Git feels like a tool I can use to create and mould meaningful commits that best convey intent. Mercurial feels like it wants to just make a literal log of what I've done, which is a bit simplistic and isn't the same as what I want to present when my code is ready. I also find the model of Git much easier to understand and explain to others.

pseudalopex 7y ago
Mercurial copied interactive rebase from Git a long time ago and refined it with phases[1]. What do you find easier to understand and explain about Git's model? [1] https://www.mercurial-scm.org/wiki/Phases https://www.mercurial-scm.org/wiki/Phases
- chrisseaton 7y ago
  Yeah they copied it. They copied it because it was better. Do you think that they copied it because it was a bad UI idea? Not sure what your point is. And great question about the Git model, after mentioning 'phases'! Mercurial has about a billion concepts and nouns for different random things like that. It takes forever to explain all the random ideas they've piled into it in an attempt to keep up with Git. Mercurial think they can fix everything with yet another plugin and new concepts and nouns. Git built a cleaner model where you don’t need these plugins and abstractions.
  - pseudalopex 7y ago
    How does Mercurial feel like "it wants to just make a literal log of what I've done"? It has a UI very similar to Git's for rewriting history and a feature specifically to help do it safely. Git copied things from Mercurial too. I don't think Git having a feature Mercurial didn't in 2007 means "Git turned out to have the better UI and architecture". Git still has the problem Mercurial phases address. A lot of Git users are annoyed that Mercurial branches work like other systems instead of Git and that it calls Git branches "bookmarks". New users understand Mercurial branches much more easily in my experience. Mercurial queues are complex but only needed for workflows Git doesn't support. They're an extension so that most people don't even need to know they exist. Do you have any other examples?
    - chrisseaton 7y ago
      > How does Mercurial feel like "it wants to just make a literal log of what I've done"? Because rebasing was literally an afterthought - a plugin. I don't think I ever push commits without rebasing them a few times. There's also now about six different ways to rewrite your history in Mercurial. It's a mess. Git has one way to do it and it's a normal part of the system. If a Mercurial user asks me how to tidy up their history my answer is 'er... well there's rebase, mq, histedit, evolve...' that's a lot of options to teach people. In Git I just show them rebase. It's all subjective isn't it? For me, less concepts, nouns, and plugins adds up to a simpler and so better architecture and UI. Maybe the extra concepts are what floats your boat and that's fine.