8 ms·

Comes up in every conversation I have about Emacs, Git, CSS, etc: Just because a tool is the best at what it does, that doesn't necessarily mean it's good at wh

Comes up in every conversation I have about Emacs, Git, CSS, etc: Just because a tool is the best at what it does, that doesn't necessarily mean it's good at what it does. Those are two different metrics. There's no danger of me dropping Git, the best alternative I've seen is Fossil and (opinion me) I think Fossil makes more mistakes than Git does. But Git definitely still has flaws; a lot of this post rings true to me. I do think that Git gets a lot better the more that you understand how it works. Not perfect, a lot of the flaws being pointed out here are core flaws with Git's internals and have nothing to do with the UI. But it does get significantly better; some of the failure modes are much easier to avoid if you've spent time digging into how Git works, and the whole thing starts to feel a lot more elegant the more that the abstractions are stripped away. But that's also kind of a flaw in itself: Git's user interface is much more complicated than the underlying program or concepts are, which is obviously not great.

sgbeal 3y ago
> the best alternative I've seen is Fossil and (opinion me) I think Fossil makes more mistakes than Git does. The fossil developers (myself included) would be interested in hearing what those mistakes are. We're open to improvement so long as they don't break backwards compatibility (e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil).
- danShumway 3y ago
  > e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil We could go further, but yeah, this is basically the biggest problem. I know this is a fundamental attribute of Fossil and that's fine, but to me it makes Fossil unusable as a VC system for most serious projects. I don't think of VC as an immutable record, I think of it as a tool for organization and collaboration that also allows me to have documentation around repository history, and I don't think that immutable history helps with either documentation or collaboration. Obviously some people disagree with me on that, but the really short answer is that I think the way Fossil defines version control is misguided, so it's unlikely I would ever make the switch over.
  - SQLite 3y ago
    Yeah - I'm very much about maintaining an immutable record. That is why, back in 2006, I started designing Fossil to control SQLite, instead of just switching to Git. I think that proper version control should be immutable. If history is changeable, what's the point in having history at all? It ceases to be "history" and becomes just a fable or hagiography. Mistakes happen, and it is important to be able to correct them, which Fossil does do. In many ways Fossil's mistake-correction logic is far better than Git's. If you make a check-in to the wrong branch, you can move it after the fact in Fossil. If you check-in with the wrong user-id, or a with a goofy check-in comment, you can edit those too. Was your system clock wonky when you did the commit, resulting in a bad timestamp on the check-in, that too can be fixed. I say "edit" - really you are not modifying the original check-in at all. The original check-in is immutable. But Fossil supports the ability to add correction records (tags) on top of check-ins. The original history is preserved and you can always drill down to find out exactly what happened. But for routine day-to-day usage, only the corrected values are shown on displays and reports. So it is like being able to change history, except that you are left with an audit trail. This is how accounting and legal systems work. You never erase - you only add corrections.
    - danShumway 3y ago
      Which is fine for someone to have as a perspective, I just think that philosophy is far too limiting for a universal VC system and misses the point of what many people use VC for. It's not so much "the people who are designing Fossil are bad at designing it" as much as it is "I disagree with their starting premises and their goals for the thing they're building." If someone comes to me and asks why they would want to use Git over Fossil, the primary thing I would point at is: > This is how accounting and legal systems work. You never erase - you only add corrections. I just personally think that can be in many situations an unhelpful way to think about what a VC is at a fundamental level; I don't think a VC is inherently an accountability system or a legal system, and I think that having that rigidity can get in the way of certain workflows. Again, opinion me, I know you're quite happy with Fossil for SQLite, and that's great and I'm sure it works great. It's not like it's bad to have opinionated tools, I just think that it gets in the way of treating Fossil as something I would recommend as a general Git replacement for everyone. It comes down to: is the ability to rewrite "history" (which is not even really history at all in Git, it's just a collection of ordered changes) a feature or a problem? Fossil thinks it's a problem, I think it's a feature. Fossil looks at repository history like a historical record, I look at repository "history" as purely an organizational tool for checkpointing/documentation.
BoiledCabbage 3y ago
That's fundamentally the issue with git. It's underlying concept is good - probably still a tad bit more convoluted than it needs to be with the benefit of hindsight, but that's fine. It's hard to design software. But it's overall user experience - the way you interact with it is horrific. It's is so incredibly convoluted. So much inessential complexity. Half of learning to use git is learning to look past the convoluted interface and see/understand the simpler concepts behind it. It's legitimately one of the largest divergences between simplicity of concepts and complexity of UX/interface of any serious tool I've ever worked with in my career. Again, it's huge service and absolutely a benefit - but also the amount of collective dev hours wasted on understanding git minutiae is way too high.
- danShumway 3y ago
  When I teach Git in mentoring situations, I start with the underlying concepts before I even touch the user interface. And that's kind of wild, it's a testament to how bad the user-facing interface is that I'm thinking about it through the lens of "understanding the internals will make the UI easier", not "understanding and working with the UI will make the internals clearer."
- yowzadave 3y ago
  If this is true, do you think it would be possible to write a new UI for git that is compatible with git repositories, but more accurately (and intuitively) exposes those underlying concepts?
martinvonz 3y ago
Jujutsu/jj (https://github.com/martinvonz/jj https://github.com/martinvonz/jj) keeps most of Git's data model and tries to improve the UX. It can even be used with existing Git repos.
- danShumway 3y ago
  Thanks, will take a look.
fouc 3y ago
>Git's user interface When I encountered git back in 2006, I was kinda surprised at the choices of git's commands & arguments, it didn't seem nearly as nice as SVN's command-line interface. But git did win out for being usable locally & the sheer speed. I kinda hoped the command-line interface would get revamped w/ better command names & better argument structure, but that never happened I guess.
- rstuart4133 3y ago
  Linux seemed to loath svn with a passion. I really some comment from him like "they simply don't get it". With the benefit of hindsight, he was right. But he did throw the baby out with the bath water. They got the data structures wrong, the overall concept skew whiff (a commit is the code at a point in time; how you got there is just meta data), but the higher level interface wasn't bad. He could have done worse than to base the porcelain command names on svn.

sgbeal 3y ago

> the best alternative I've seen is Fossil and (opinion me) I think Fossil makes more mistakes than Git does. The fossil developers (myself included) would be interested in hearing what those mistakes are. We're open to improvement so long as they don't break backwards compatibility (e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil).

danShumway 3y ago
> e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil We could go further, but yeah, this is basically the biggest problem. I know this is a fundamental attribute of Fossil and that's fine, but to me it makes Fossil unusable as a VC system for most serious projects. I don't think of VC as an immutable record, I think of it as a tool for organization and collaboration that also allows me to have documentation around repository history, and I don't think that immutable history helps with either documentation or collaboration. Obviously some people disagree with me on that, but the really short answer is that I think the way Fossil defines version control is misguided, so it's unlikely I would ever make the switch over.
- SQLite 3y ago
  Yeah - I'm very much about maintaining an immutable record. That is why, back in 2006, I started designing Fossil to control SQLite, instead of just switching to Git. I think that proper version control should be immutable. If history is changeable, what's the point in having history at all? It ceases to be "history" and becomes just a fable or hagiography. Mistakes happen, and it is important to be able to correct them, which Fossil does do. In many ways Fossil's mistake-correction logic is far better than Git's. If you make a check-in to the wrong branch, you can move it after the fact in Fossil. If you check-in with the wrong user-id, or a with a goofy check-in comment, you can edit those too. Was your system clock wonky when you did the commit, resulting in a bad timestamp on the check-in, that too can be fixed. I say "edit" - really you are not modifying the original check-in at all. The original check-in is immutable. But Fossil supports the ability to add correction records (tags) on top of check-ins. The original history is preserved and you can always drill down to find out exactly what happened. But for routine day-to-day usage, only the corrected values are shown on displays and reports. So it is like being able to change history, except that you are left with an audit trail. This is how accounting and legal systems work. You never erase - you only add corrections.
  - danShumway 3y ago
    Which is fine for someone to have as a perspective, I just think that philosophy is far too limiting for a universal VC system and misses the point of what many people use VC for. It's not so much "the people who are designing Fossil are bad at designing it" as much as it is "I disagree with their starting premises and their goals for the thing they're building." If someone comes to me and asks why they would want to use Git over Fossil, the primary thing I would point at is: > This is how accounting and legal systems work. You never erase - you only add corrections. I just personally think that can be in many situations an unhelpful way to think about what a VC is at a fundamental level; I don't think a VC is inherently an accountability system or a legal system, and I think that having that rigidity can get in the way of certain workflows. Again, opinion me, I know you're quite happy with Fossil for SQLite, and that's great and I'm sure it works great. It's not like it's bad to have opinionated tools, I just think that it gets in the way of treating Fossil as something I would recommend as a general Git replacement for everyone. It comes down to: is the ability to rewrite "history" (which is not even really history at all in Git, it's just a collection of ordered changes) a feature or a problem? Fossil thinks it's a problem, I think it's a feature. Fossil looks at repository history like a historical record, I look at repository "history" as purely an organizational tool for checkpointing/documentation.

BoiledCabbage 3y ago

That's fundamentally the issue with git. It's underlying concept is good - probably still a tad bit more convoluted than it needs to be with the benefit of hindsight, but that's fine. It's hard to design software. But it's overall user experience - the way you interact with it is horrific. It's is so incredibly convoluted. So much inessential complexity. Half of learning to use git is learning to look past the convoluted interface and see/understand the simpler concepts behind it. It's legitimately one of the largest divergences between simplicity of concepts and complexity of UX/interface of any serious tool I've ever worked with in my career. Again, it's huge service and absolutely a benefit - but also the amount of collective dev hours wasted on understanding git minutiae is way too high.

danShumway 3y ago
When I teach Git in mentoring situations, I start with the underlying concepts before I even touch the user interface. And that's kind of wild, it's a testament to how bad the user-facing interface is that I'm thinking about it through the lens of "understanding the internals will make the UI easier", not "understanding and working with the UI will make the internals clearer."
yowzadave 3y ago
If this is true, do you think it would be possible to write a new UI for git that is compatible with git repositories, but more accurately (and intuitively) exposes those underlying concepts?

martinvonz 3y ago

Jujutsu/jj (https://github.com/martinvonz/jj https://github.com/martinvonz/jj) keeps most of Git's data model and tries to improve the UX. It can even be used with existing Git repos.

danShumway 3y ago
Thanks, will take a look.

fouc 3y ago

>Git's user interface When I encountered git back in 2006, I was kinda surprised at the choices of git's commands & arguments, it didn't seem nearly as nice as SVN's command-line interface. But git did win out for being usable locally & the sheer speed. I kinda hoped the command-line interface would get revamped w/ better command names & better argument structure, but that never happened I guess.

rstuart4133 3y ago
Linux seemed to loath svn with a passion. I really some comment from him like "they simply don't get it". With the benefit of hindsight, he was right. But he did throw the baby out with the bath water. They got the data structures wrong, the overall concept skew whiff (a commit is the code at a point in time; how you got there is just meta data), but the higher level interface wasn't bad. He could have done worse than to base the porcelain command names on svn.