Things I just don't like about Git(cohost.org)
cohost.org
Things I just don't like about Git
https://cohost.org/tef/post/3009746-things-i-just-don-t
117 comments
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.
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.
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."
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?
Jujutsu/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.
Thanks, will take a look.
> 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).
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).
> 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.
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.
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.
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.
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.
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.
> I just personally think that can be in many situations an unhelpful way to think about what a VC is at a fundamental level;
The Devil's Advocate in me feels compelled to point out that git is (to the very best of my fallible knowledge) the _only_ SCM in history to permit rewriting of history. Certainly SVN, CVS, and their predecessors did not get it all wrong by not enabling editing of history?
Admittedly, rebase/squashing/etc. is _necessary_ for a Linux-kernel-scale project, but 99.99+% of software projects are, in terms of the number of contributors/contributions, so far removed from that scale as to not even register on that scale.
The Devil's Advocate in me feels compelled to point out that git is (to the very best of my fallible knowledge) the _only_ SCM in history to permit rewriting of history. Certainly SVN, CVS, and their predecessors did not get it all wrong by not enabling editing of history?
Admittedly, rebase/squashing/etc. is _necessary_ for a Linux-kernel-scale project, but 99.99+% of software projects are, in terms of the number of contributors/contributions, so far removed from that scale as to not even register on that scale.
Other version control systems don’t give you tools to manage your work while it is being prepared and reviewed, before it is committed to the shared repository. That is when much of the rewriting happens.
> The Devil's Advocate in me feels compelled to point out that git is the _only_ SCM in history to permit rewriting of history. Certainly SVN, CVS, and their predecessors did not get it all wrong by not enabling editing of history?
There are a lot of reasons I don't use SVN and CVS, but correct, their branch model is one of them. I do think that Git's restructuring of how commits and branches work and the flexibility around them is one of the reasons its better than older VC systems.
I'm not sure how strict those older VCs actually were, I'm less familiar with them than I am with Git/Fossil, but... yeah I have no problem saying that if they were doing fully immutable history they were wrong to do so (or maybe "wrong" isn't the best term to use, more that it would be an attribute that I think would make them less useful to a lot of developers).
> 99.99+% of software projects are, in terms of the number of contributors/contributions, so far removed from that scale as to not even register on that scale.
I would disagree with this, I think rebasing/squashing is just a really useful tool, even for smaller projects. It's sort of a difficult debate to have because it's mostly going to come down to opinion. What does necessary mean in a smaller project, VC itself is not strictly necessary for many smaller projects.
SQLite gets by fine with Fossil, the developer prefers having an immutable history. But I'm not sure what to say other than that I use rebasing a lot. Different projects have different development styles.
There are a lot of reasons I don't use SVN and CVS, but correct, their branch model is one of them. I do think that Git's restructuring of how commits and branches work and the flexibility around them is one of the reasons its better than older VC systems.
I'm not sure how strict those older VCs actually were, I'm less familiar with them than I am with Git/Fossil, but... yeah I have no problem saying that if they were doing fully immutable history they were wrong to do so (or maybe "wrong" isn't the best term to use, more that it would be an attribute that I think would make them less useful to a lot of developers).
> 99.99+% of software projects are, in terms of the number of contributors/contributions, so far removed from that scale as to not even register on that scale.
I would disagree with this, I think rebasing/squashing is just a really useful tool, even for smaller projects. It's sort of a difficult debate to have because it's mostly going to come down to opinion. What does necessary mean in a smaller project, VC itself is not strictly necessary for many smaller projects.
SQLite gets by fine with Fossil, the developer prefers having an immutable history. But I'm not sure what to say other than that I use rebasing a lot. Different projects have different development styles.
Subversion had plans to let administrators remove files or commits. Git inspired Mercurial's history editing.
Last time I used SVN I rebased all the time, no problem. I was using a git-to-svn bridge though. My point is, people will rewrite history on their own computer whether you want them to or not. Git is the only VCS that doesn't fight against that fact.
> 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.
Many git users agree, including the kernel from memory. By that I mean there is often some git tree (maybe called "production", "main" or "master") were "fast roll forward" is the only style of commit accepted. Ie, on that tree, you can't change history. But when you're using git to built a commit to that tree, you are allowed (and in the kernel's case expected), to clean the history up, removing all your mistakes and experiments, so the people following the main branch don't have to wade through all that crap.
So the difference is git allows it to be a policy setting, whereas I take it Fossil forces it to be turtles all the way down.
Many git users agree, including the kernel from memory. By that I mean there is often some git tree (maybe called "production", "main" or "master") were "fast roll forward" is the only style of commit accepted. Ie, on that tree, you can't change history. But when you're using git to built a commit to that tree, you are allowed (and in the kernel's case expected), to clean the history up, removing all your mistakes and experiments, so the people following the main branch don't have to wade through all that crap.
So the difference is git allows it to be a policy setting, whereas I take it Fossil forces it to be turtles all the way down.
History is only immutable once it's committed to Fossil, and anything not committed is lost forever. This may sound banally obvious, but I think it's fundamentally the problem with Fossil's approach. With git I essentially commit my entire undo/redo stack. I end up discarding most of that later, while with Fossil I would never have committed those intermediate versions in the first place.
Without history rewriting, the rewriting simply takes place before committing instead of after.
Without history rewriting, the rewriting simply takes place before committing instead of after.
Only if you choose to use it like that. I commit every minor detail in Fossil, even little things like "added TODO comment".
I use fossil as my daily driver VCS and I feel like it doesn't go far enough in it's ability to non-destructively amend history. The canonical justification for git-style rewriting is taking all the commits that make up some feature and smashing them down into one "implemented feature X" commit which, as far as I know (?), does not have an analogue in Fossil. Even something like forgetting to add a file to a commit requires an additional commit (and shows up as such on the timeline) with a silly "forgot to include file foo in commit whatever" comment.
Ideally there'd be some kind of "virtual commit" capable of (visually) bundling up a range of commits, with its own message and tags; maybe these could be nested so that you could have a hierarchical view of the timeline: initially you see "release X, release Y" but then you can expand any of those to "implemented feature A, B" which can be further expanded into the actual commits.
Ideally there'd be some kind of "virtual commit" capable of (visually) bundling up a range of commits, with its own message and tags; maybe these could be nested so that you could have a hierarchical view of the timeline: initially you see "release X, release Y" but then you can expand any of those to "implemented feature A, B" which can be further expanded into the actual commits.
Git made the only choice a popular VCS can make. History rewrites will exist, period. If you're opposed to history rewrites, then git gives you the tools to ensure the repos you control are not rewritten, and that's all it can do in a world where people have control of their own computers.
If Fossil ever becomes as popular as git, people will create software that allows history rewriting in Fossil.
Another user in this thread linked to jj [0], an alternative git client that does some pretty weird things. For example, it replaces the working tree with a working commit and commits quite often. I like git and that seems weird to me, but I'm not offended, people can do what they want on their own computer and I have the tools to ensure repos under my control are not affected. That's all I can hope for, and I'm happy that jj makes git more usable for some people.
[0]: https://github.com/martinvonz/jj
If Fossil ever becomes as popular as git, people will create software that allows history rewriting in Fossil.
Another user in this thread linked to jj [0], an alternative git client that does some pretty weird things. For example, it replaces the working tree with a working commit and commits quite often. I like git and that seems weird to me, but I'm not offended, people can do what they want on their own computer and I have the tools to ensure repos under my control are not affected. That's all I can hope for, and I'm happy that jj makes git more usable for some people.
[0]: https://github.com/martinvonz/jj
It's more than inevitability to me; on some level I would almost say that "history" in Git is the wrong name. I've had conversations with Fossil devs before where they referred to rewriting history as a "white lie" and I just don't agree with that framing, I don't think it's a lie at all.
Git's history can correspond to actual history in reality and that can be a useful way to add accountability to a project (although of course as you say, you have no control over history coming from someone else's computer). But Git's "history" doesn't have to correspond to actual history in reality, and very often that's not how I'm using it. So I don't think when I rebase I'm lying because I don't believe I'm making any claim at all about the physical reality of how the code was written. I'm organizing feature commits on a timeline.
To me it's a little odd to look at that and to say "you're trying to change history." No, I'm not, I'm not saying anything at all about history when I do a rebase. I am grouping code together into logical units and putting them on a timeline so that they make sense when read sequentially. That's all I'm doing. If I came to you and said "this rebase perfectly represents the development history", sure that would be a lie. But I'm not saying that, and I don't think it's inherently the job of a VC system to claim that. I think the most important job of a version control system is to... well... control versions, and immutably showcasing a record of how the project was built is a secondary concern.
:shrug: At least the way I use VCs, I guess other people's millage may vary.
Git's history can correspond to actual history in reality and that can be a useful way to add accountability to a project (although of course as you say, you have no control over history coming from someone else's computer). But Git's "history" doesn't have to correspond to actual history in reality, and very often that's not how I'm using it. So I don't think when I rebase I'm lying because I don't believe I'm making any claim at all about the physical reality of how the code was written. I'm organizing feature commits on a timeline.
To me it's a little odd to look at that and to say "you're trying to change history." No, I'm not, I'm not saying anything at all about history when I do a rebase. I am grouping code together into logical units and putting them on a timeline so that they make sense when read sequentially. That's all I'm doing. If I came to you and said "this rebase perfectly represents the development history", sure that would be a lie. But I'm not saying that, and I don't think it's inherently the job of a VC system to claim that. I think the most important job of a version control system is to... well... control versions, and immutably showcasing a record of how the project was built is a secondary concern.
:shrug: At least the way I use VCs, I guess other people's millage may vary.
> then git gives you the tools to ensure the repos you control are not rewritten
I might betray my ignorance here, but what tools are those?
If I host a git repo, then I can obviously ensure that any branches on the origin are never rewritten. But how can I ensure that people who submit pull requests have not rewritten their history?
I might betray my ignorance here, but what tools are those?
If I host a git repo, then I can obviously ensure that any branches on the origin are never rewritten. But how can I ensure that people who submit pull requests have not rewritten their history?
> I can obviously ensure that any branches on the origin are never rewritten
That is all I meant. As you say, people can still rewrite their own history on their own computer before submitting it.
We could get philosophical about what "history" is. If I press backspace am I rewriting history? What granularity are we talking here? If I make change X by frequently committing and then squash, have I rewritten history? If I make the exact same change X with one big commit at the end (no squashing), have I not rewritten history? Whether or not I rewrote history the pull request at the end is the same. Or what if I'm using jj which amends a "working commit" hundreds of times, have I rewritten history?
Ultimately the division of changes into commits is a matter of authorship, a creative endeavor. I'd prefer to do this creative work with whatever tools I choose, but if you force me to never squash, I can still achieve the same creative output using other tools or by altering how I work. At no point were commits ever an actual history, they were always a presentation of the history the author chose to present.
(I've rambled on here, most of this isn't meant as a direct reply to you.)
That is all I meant. As you say, people can still rewrite their own history on their own computer before submitting it.
We could get philosophical about what "history" is. If I press backspace am I rewriting history? What granularity are we talking here? If I make change X by frequently committing and then squash, have I rewritten history? If I make the exact same change X with one big commit at the end (no squashing), have I not rewritten history? Whether or not I rewrote history the pull request at the end is the same. Or what if I'm using jj which amends a "working commit" hundreds of times, have I rewritten history?
Ultimately the division of changes into commits is a matter of authorship, a creative endeavor. I'd prefer to do this creative work with whatever tools I choose, but if you force me to never squash, I can still achieve the same creative output using other tools or by altering how I work. At no point were commits ever an actual history, they were always a presentation of the history the author chose to present.
(I've rambled on here, most of this isn't meant as a direct reply to you.)
Ah, fair enough!
On my team we use pre-commit[0] a lot. I guess I would define the history to be something like "has this commit ever been run through our pre-commit hooks?". If you rewrite history, you'll (usually) produce commits that have not been through pre-commit (and they've therefore dodged a lot of static checks that might catch code that wasn't working, at that point in time). That gives some manner of objectivity to the "history", although it does depend on each user having their pre-commit hooks activated in their local workspace.
[0]: https://pre-commit.com/
On my team we use pre-commit[0] a lot. I guess I would define the history to be something like "has this commit ever been run through our pre-commit hooks?". If you rewrite history, you'll (usually) produce commits that have not been through pre-commit (and they've therefore dodged a lot of static checks that might catch code that wasn't working, at that point in time). That gives some manner of objectivity to the "history", although it does depend on each user having their pre-commit hooks activated in their local workspace.
[0]: https://pre-commit.com/
>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.
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.
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.
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.
https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki
git doesn't suck. It's the best possible version control system in the context where it was produced, i.e. the Linux Kernel, i.e. an ultra large bazaar style project with hundreds of developers gifted at getting the low level details right.
It was not however designed for the kind of projects I work on, more Cathedral style, a few people who know and trust each other, where learnability, usability, and just not getting in the way are important factors.
The SQLite people have a concurrent to git called fossil. I found their description of why they started and maintain the project incredibly interesting
git doesn't suck. It's the best possible version control system in the context where it was produced, i.e. the Linux Kernel, i.e. an ultra large bazaar style project with hundreds of developers gifted at getting the low level details right.
It was not however designed for the kind of projects I work on, more Cathedral style, a few people who know and trust each other, where learnability, usability, and just not getting in the way are important factors.
The SQLite people have a concurrent to git called fossil. I found their description of why they started and maintain the project incredibly interesting
There was a podcast with the author of SQLite explaining pretty much why he doesn't use anything by anyone else.
> There was a podcast with the author of SQLite explaining pretty much why he doesn't use anything by anyone else.
To summarize, his (Richard Hipp's) definition of freedom is "being able to take care of yourself." That includes reducing third-party software dependencies to the absolute minimum (e.g. libssl is not something he wants to reimplement... though we have (very) idly tossed the idea around ;)).
To summarize, his (Richard Hipp's) definition of freedom is "being able to take care of yourself." That includes reducing third-party software dependencies to the absolute minimum (e.g. libssl is not something he wants to reimplement... though we have (very) idly tossed the idea around ;)).
I love these posts. I bookmark all of them.
I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.)
I'd love to hear more about what people hate about Git.
I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.)
I'd love to hear more about what people hate about Git.
Back in a day, late 00s, early 10s, Git had alternatives.
- Bazaar
- Mercurial (Hg)
Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible.
What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user interface. Early days, Github itself had a lot of competition. Bitbucket (now Atlassian) was the same but for Mercurial. However, Github, as a good American startup, won over the world, popularising Git along the way.
(Also Stackoverflow helped a lot. There isn’t a day I won’t Google how to do basic things in Git.)
- Bazaar
- Mercurial (Hg)
Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible.
What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user interface. Early days, Github itself had a lot of competition. Bitbucket (now Atlassian) was the same but for Mercurial. However, Github, as a good American startup, won over the world, popularising Git along the way.
(Also Stackoverflow helped a lot. There isn’t a day I won’t Google how to do basic things in Git.)
I wish I lived in an alternate timeline where a delightfully unpronounceable service called HgHub had won the day instead. But on a more open-minded note, would Github been just as successful if they had used something other than Git for the backend? Or was Git already popular enough that Github had essentially no other choice but to use it instead of another DVCS if they wanted to become the dominant player in their space?
When GitHub was the new kid on the block, it's competition was largely Google code and source forge.
Google code was svn and git. Source forge was the same, but also had CVS.
Google code was svn and git. Source forge was the same, but also had CVS.
Bitbucket was the original Mercurial hosting site. They only added git years later after it was clear that Mercurial had (at best) stalled, and removed Mercurial when it was clear that no one cared about it anymore.
It was called "Kiln" and integrated beautifully with FogBugz (both from Fog Creek). We used them for nearly 10 years.
BitBucket no longer supports Mercurial, only Git.
Thankfully, SourceHut does support Mercurial (and, IIRC, it also supports Fossil).
Thankfully, SourceHut does support Mercurial (and, IIRC, it also supports Fossil).
Back then, when I had only subversion experience, I tried both git and mercurial, and found mercurial really confusing. Ended up using git for everything, the way it worked just made sense to me.
Unfortunately it's been long enough that I don't remember any details about why I found mercurial confusing.
Unfortunately it's been long enough that I don't remember any details about why I found mercurial confusing.
I was using git before github was even a thing. Ruby on Rails community was already moving to git in 2006 & 2007. Github was created by a couple of Rails developers that saw the popularity of git and responded.
I also tried Darcs, Bazaar & Mercurial back then. Those options were slooowww. Git largely won because it was blazing fast, and easy to understand. Probably having the cachet of Linus helped. I personally found transitioning from svn to git was a breeze.
I do have some quibbles about the structure of commands & arguments from an UX perspective with git, but ultimately it wasn't a dealbreaker.
I also tried Darcs, Bazaar & Mercurial back then. Those options were slooowww. Git largely won because it was blazing fast, and easy to understand. Probably having the cachet of Linus helped. I personally found transitioning from svn to git was a breeze.
I do have some quibbles about the structure of commands & arguments from an UX perspective with git, but ultimately it wasn't a dealbreaker.
> Both had superior user experience compared to git
Highly subjective.
Both Mercurial and Bazaar were plagued a long time by muddled branching and collaboration story. In hg there were the anonymous branches, multiple repos, bookmarks, all worked in different ways and their interactions were confusing. Bazaar I didn't use much but remember not understanding at all its branching model then, and didn't bother finding out.
Git won because it got many things right from the start, and was better than the competition.
Highly subjective.
Both Mercurial and Bazaar were plagued a long time by muddled branching and collaboration story. In hg there were the anonymous branches, multiple repos, bookmarks, all worked in different ways and their interactions were confusing. Bazaar I didn't use much but remember not understanding at all its branching model then, and didn't bother finding out.
Git won because it got many things right from the start, and was better than the competition.
git gained popularity way before github/gitlab. Its popularity stemmed from the features that CVS and SVN were severely lacking. Github just made it easier to share and discover projects, and it happened to use git. It also helps that github was not a target for foss, instead it was started as a business. Before then, git, cvs, svn, were all foss projects and hosted (usually mostly) by the project owners.
Define popularity? SVN was still the majority platform because Sourceforge and Google Code were the most popular publicly accessible project hosting platforms. A lot of the self-hosted projects were still on CVS repos, often without anonymous access, so you'd just get tarballs of the source code with releases as a non-contributor. My memory is definitely that github adoption drove git adoption by basically its code first approach being more appealing to developers than Sourceforge/Google Code's project first approach.
Later on stuff like git-flow came along which also helped people have a process to migrate to (even if it's poorly suited for the development patterns software projects were already migrating to at the time).
Later on stuff like git-flow came along which also helped people have a process to migrate to (even if it's poorly suited for the development patterns software projects were already migrating to at the time).
Also open source developers had to find a new home
- SourceForge had become questionable with its inclusion of its own malware in installers https://arstechnica.com/information-technology/2016/06/under...
- Google Code was untrusted, because they have a tendency to rug pull their products now and then
Github served a market need.
For others
- Bazaar was too Ubuntu specific (was in-house Ubuntu project originally)
- Bitbucket kind of survived as Atlassian
- SourceForge had become questionable with its inclusion of its own malware in installers https://arstechnica.com/information-technology/2016/06/under...
- Google Code was untrusted, because they have a tendency to rug pull their products now and then
Github served a market need.
For others
- Bazaar was too Ubuntu specific (was in-house Ubuntu project originally)
- Bitbucket kind of survived as Atlassian
> (Also Stackoverflow helped a lot. There isn’t a day I won’t Google how to do basic things in Git.)
Back in 2011 or 2012 i once had one of the libgit developers sitting at my workstation for a full hour trying un-hose my local checkout after i'd made the mistake of following git instructions from SO.
SO git advice: 0 of 5 stars. Cannot recommend.
Back in 2011 or 2012 i once had one of the libgit developers sitting at my workstation for a full hour trying un-hose my local checkout after i'd made the mistake of following git instructions from SO.
SO git advice: 0 of 5 stars. Cannot recommend.
Scrap the thing entirely and replace it with something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. Folders instead of branches. Be 100% language-aware; any merge result has to build obviously.
If this rejects actions and limits possibilities that Git provides, so be it.
If this rejects actions and limits possibilities that Git provides, so be it.
You will immediately find that people use version control differently and "undo" means different things for them, therefore you have either:
a) 50 variants of "undo"
b) one official undo, but "here we use git foo" because reasons
c) people operating directly on the repo structure because a) and b) are to complicated and broken for some specific workflow.
d) most likely - mix of all those options.
What I don't get is why people insist on using git directly.
Define your workflow and create aliases named "undo", "save" etc. that work with folders instead of branches if you wish, call it our_git and use it. I've seen people do something like that.
I agree. You laid out my current design in a nutshell, actually. Except for folders. But my branches will be more than a bookmark.
In your design, can I go to the other "branch/folder" and look around / copy over that binary to my current "branch/folder" in a file explorer without a "checkout"?
Not in a file explorer, sadly.
However, I was going to make a browser UI from the start. I could implement a branch and file explorer in that UI, which would allow you to do the same thing.
Would that be good enough or not? I'd love to know because I want to build this tool for humans first.
However, I was going to make a browser UI from the start. I could implement a branch and file explorer in that UI, which would allow you to do the same thing.
Would that be good enough or not? I'd love to know because I want to build this tool for humans first.
Probably, yes. Anything that does not require thinking in current Git-logic. I don't mind Git that much in everyday work but if something nicer came along, that would be great.
I do think that Git is very well established, and it would probably take a major player, maybe Azure or AWS with a cloud-based IDE to change paradigms.
I do think that Git is very well established, and it would probably take a major player, maybe Azure or AWS with a cloud-based IDE to change paradigms.
Thank you.
I just realized something: maybe I can make it so regular file explorers work.
I had intended to use something like Fossil's checkouts. I could formalize it; each branch the user wants could be a separate directory in the repo directory.
While I hate that, people seem to like it. I think I will do it.
Thank you for pointing me in the right direction.
I just realized something: maybe I can make it so regular file explorers work.
I had intended to use something like Fossil's checkouts. I could formalize it; each branch the user wants could be a separate directory in the repo directory.
While I hate that, people seem to like it. I think I will do it.
Thank you for pointing me in the right direction.
It's not impossible - https://github.com/g2p/git-fs did this a long while back and https://github.com/presslabs/gitfs did something similar too.
Good luck!
I think folders instead of branches is a mistake, because folders are a tree but branches are a graph.
> I'd love to hear more about what people hate about Git.
It's not implemented as a single portable library. This makes embedding or driving git from other programs—a thing I've wanted or needed to do several times in my career, so I'm pretty sure it's really common—suck a lot more than it needs to.
It's not implemented as a single portable library. This makes embedding or driving git from other programs—a thing I've wanted or needed to do several times in my career, so I'm pretty sure it's really common—suck a lot more than it needs to.
Have you looked into libgit2?
https://libgit2.org/
https://libgit2.org/
1) It’s not at feature parity,
And
2) It’s not the official implementation, so using it is committing to debug and work around divergence between it and actual git, probably after production or otherwise in-use data have been messed up.
And
2) It’s not the official implementation, so using it is committing to debug and work around divergence between it and actual git, probably after production or otherwise in-use data have been messed up.
Good to know. I'll make mine a library and tool, like SQLite.
Many years ago, when I was looking for a worthy DVCS successor to Subversion for my single-developer projects (just in case they became multiple-developer projects), I evaluated Git, Bazaar, and Mercurial. I don't really remember what were the deciding factors, but I ended up going with Mercurial. I'm sure usability was a big part of it, since that's a major value for me, and I really didn't like git in that department. I think I also read some things that made me distrust git's handling of data, but don't remember the specifics. git just seems messy in other ways as well. I still wonder to this day whether the wrong DVCS won the popularity contest and became an unfortunate default option for developers.
Yeah I think the point about monorepos vs submodules is probably the biggest non-usability issue with Git.
In a very large project you can have a monorepo, and then everything is slow and you can't easily use and work on a subset of the code.
Or you can use submodules and then testing, refactoring and making commits all become a nightmare.
Binary files is another crap area of Git. LFS is useless. Lots of people have Stockholm syndrome and think that Git doesn't support large/binary files well because it's immoral rather than just because it's not something Linus ever needed.
I'm still a bit sad that most of the attempts at replacing Git focus on the poor conflict resolution story (which is poor but tolerable) rather than these more fundamental issues.
In a very large project you can have a monorepo, and then everything is slow and you can't easily use and work on a subset of the code.
Or you can use submodules and then testing, refactoring and making commits all become a nightmare.
Binary files is another crap area of Git. LFS is useless. Lots of people have Stockholm syndrome and think that Git doesn't support large/binary files well because it's immoral rather than just because it's not something Linus ever needed.
I'm still a bit sad that most of the attempts at replacing Git focus on the poor conflict resolution story (which is poor but tolerable) rather than these more fundamental issues.
> Yeah I think the point about monorepos vs submodules is probably the biggest non-usability issue with Git.
As a lone developer, I admit that this is what surprises me the most about the experience of other people.
But I'm going to solve it. Partial checkouts, fully-transactional cross-submodule commits, the works.
Really, these problems are easy with a good design. It's unfortunate that Linus didn't have time for design.
> Binary files is another crap area of Git. LFS is useless. Lots of people have Stockholm syndrome and think that Git doesn't support large/binary files well because it's immoral rather than just because it's not something Linus ever needed.
Yeah, I don't get this either.
I am implementing a general plugin system for creating format-aware operations. This will include source code and binary files.
> I'm still a bit sad that most of the attempts at replacing Git focus on the poor conflict resolution story (which is poor but tolerable) rather than these more fundamental issues.
I fully agree. I'm going to the doing UX studies, and that's my first priority.
I am going to handle conflict resolution better, though.
As a lone developer, I admit that this is what surprises me the most about the experience of other people.
But I'm going to solve it. Partial checkouts, fully-transactional cross-submodule commits, the works.
Really, these problems are easy with a good design. It's unfortunate that Linus didn't have time for design.
> Binary files is another crap area of Git. LFS is useless. Lots of people have Stockholm syndrome and think that Git doesn't support large/binary files well because it's immoral rather than just because it's not something Linus ever needed.
Yeah, I don't get this either.
I am implementing a general plugin system for creating format-aware operations. This will include source code and binary files.
> I'm still a bit sad that most of the attempts at replacing Git focus on the poor conflict resolution story (which is poor but tolerable) rather than these more fundamental issues.
I fully agree. I'm going to the doing UX studies, and that's my first priority.
I am going to handle conflict resolution better, though.
Will your VCS be compatible with git pull, git push, and the file format on disk used by git?
No. I'll be using SQLite and weave files in order to handle massive amounts of data (terabytes or more) while having full transactions.
How do weave files cope with history diverging across copies, moves, and deletes? How do they handle file/directory conflicts across different branches?
History diverging is only a problem if the same branch is different across different checkouts. Since Git's branches are a bookmark, this is a problem for Git.
My tool has full branches, and your master branch is considered a different branch than the default master of the origin remote.
And to handle them across branches, each branch will have its own weave file, rooted at a parent. (There will be some optimizations.)
My tool has full branches, and your master branch is considered a different branch than the default master of the origin remote.
And to handle them across branches, each branch will have its own weave file, rooted at a parent. (There will be some optimizations.)
> sure enough, when you store names in the files, you have to rewrite history when someone changes email address, but in another world, you'd use a uuid and a file called .gitauthors that maps one to the other—and you wouldn't even have to put email addresses in the file, you could just put github urls or similar.
I mean, it's called .mailmap, and it's a map of commit email to cannonical email instead of uuid to canonical email, but this basically exists: https://git-scm.com/docs/gitmailmap
I mean, it's called .mailmap, and it's a map of commit email to cannonical email instead of uuid to canonical email, but this basically exists: https://git-scm.com/docs/gitmailmap
Git is what a software version control would look like if it were created by kernel devs who only knew C and Perl.
True. However this mix of C and Perl works. I remember early days of git and whenever someone tried to bring Mercurial (or something else), the answer for any non-trivial "how do I do X" in git was "here are some magic commands" and the answer from mercurial guys was "oh... you can't, the plugin for that doesn't exist yet". And that's how git won (well, it was also faster). And later came Github.
Latest contender is https://pijul.org/ , which claims easier conflict resolution, ability to work with part of repository and handling of binary files, but so far completely misses social aspect.
I'm dying laughing
> submodules? they're a file in the repo with a special type inside the trees, git knows when checking out that the file is special, and could run other commands. it then does not run those commands and the person using submodules begins crying.
For a while, at my company, we used a git submodule (err, I unfortunately used a git submodule... this was my fault) and it was tradition for every new engineer to have a bad deploy because git silently ignores the submodule not existing on disk. So they would deploy, the submodule would be missing, and boom.
> submodules? they're a file in the repo with a special type inside the trees, git knows when checking out that the file is special, and could run other commands. it then does not run those commands and the person using submodules begins crying.
For a while, at my company, we used a git submodule (err, I unfortunately used a git submodule... this was my fault) and it was tradition for every new engineer to have a bad deploy because git silently ignores the submodule not existing on disk. So they would deploy, the submodule would be missing, and boom.
Just wait until you bisect in a tree that contains a submodule, forget the mandatory manual update step, and your day long bisection is wasted.
If you have to bisect across commits that added or removed a submodule you might as well give up now.
If you have to bisect across commits that added or removed a submodule you might as well give up now.
Your deploy process says nothing if several (possibly thousands? a submodule can be big) files are missing and this is a complaint you have about git? It sounds like more of a complaint about the deploy process.
There certainly were defects in the deploy process, and we have since moved to a much better method. This was our docs tree, so it didn't break the code, just the, well, public documentation.
It just was annoying that you can use a submodule but git will happily ignore it not existing. It just made the whole thing super janky.
It just was annoying that you can use a submodule but git will happily ignore it not existing. It just made the whole thing super janky.
I wrote my company's git wrapper. It was meant to standardize our workflow and to be communal memory for every lesson learned and sharpened edge shaved.
It's now 6000 lines of bash.
(Ok, I'm a little proud of it. I'll open source it as soon as I rewrite it in Python.)
It's now 6000 lines of bash.
(Ok, I'm a little proud of it. I'll open source it as soon as I rewrite it in Python.)
How do you reconcile this with the fact that the vast majority of git users, both at small and large scales, do not need to do this? Now you have a massive, proprietary to your company, system for committing code that every person that joins the company has to learn and maintain.
That's a good question. My wrapper isn't meant to insulate the users from git, it's meant to teach git. It shows every git command it runs and gives the user an easier on-ramp.
> I'll open source it as soon as I rewrite it in Python.
Realistically speaking, will that happen? Why not throw up the bash code as a separate repository from the python one anyways? As an example. Could throw it into archived mode right after or something perhaps.
Realistically speaking, will that happen? Why not throw up the bash code as a separate repository from the python one anyways? As an example. Could throw it into archived mode right after or something perhaps.
It will happen, but if you want to see the bash, warts and all, here you go.
https://github.com/enfabrica/enkit/blob/master/scripts/gee
One of the big issues you'll find is that some off the defaults are very specific to my company. I'll fix that in the rewrite.
https://github.com/enfabrica/enkit/blob/master/scripts/gee
One of the big issues you'll find is that some off the defaults are very specific to my company. I'll fix that in the rewrite.
Is it easier to learn the simple concepts of git and have transferable knowledge, or to learn your proprietary 6000 line bash script?
It's easier to support a company of users when everybody is using the vcs tool in a consistent way.
I suppose. I'm bitter because I worked at a company where they wanted git used a certain way, which is fine, manage the main repo however you want. The main repo should have some standards and I will follow them. (Preferably this will be automated to for consistency and to keep egos out of the process.)
However, they overstepped and gave me a hard time when they learned I was managing my own local repo how I wanted. I'm relatively good with git and would clean up my pull requests to meet the standards before submitting them to the main repo, but they still hassled me over the naming of my local branches and doing local rebases, etc.
However, they overstepped and gave me a hard time when they learned I was managing my own local repo how I wanted. I'm relatively good with git and would clean up my pull requests to meet the standards before submitting them to the main repo, but they still hassled me over the naming of my local branches and doing local rebases, etc.
That seems unnecessary. Maybe you made someone feel threatened.
I think GitHub is half the problem with how people perceive Git.
There are friction points between how Git works and how GitHub wants to do them.
Rebase is a nice compromise between merge which makes reading history and hard and squash which loses intermediate commits (sometimes breaking rename detection). But of course you cannot include a reference to the PR anymore outside the GitHub UI or manually rewriting commits.
Similarly having the type of merge be treated as a last second choice instead of part of the reviewable flow increases "wrong button" incidents a lot.
There are friction points between how Git works and how GitHub wants to do them.
Rebase is a nice compromise between merge which makes reading history and hard and squash which loses intermediate commits (sometimes breaking rename detection). But of course you cannot include a reference to the PR anymore outside the GitHub UI or manually rewriting commits.
Similarly having the type of merge be treated as a last second choice instead of part of the reviewable flow increases "wrong button" incidents a lot.
The number of people who will insist that Git needs to be this way because of its power. If only you would bother to study the internals, you would see how beautiful it is on the inside. Why don't you just learn your craft?
Like, fine, you are just so much smarter than me. I have spent many hours going through tutorials and the documents, and I still run into problems from time to time on doing things that feel like they should be routine.
I can have a surface level understanding of most other tools without fear of breaking the world.
Like, fine, you are just so much smarter than me. I have spent many hours going through tutorials and the documents, and I still run into problems from time to time on doing things that feel like they should be routine.
I can have a surface level understanding of most other tools without fear of breaking the world.
> git for windows does "merge rebase" commits that preserve history during rebases: it creates a merge commit with the latest version, replays the existing commits atop...
Could someone show what this command looks like or link to docs? Searching for it produces a lot of rebase Vs merge results.
Could someone show what this command looks like or link to docs? Searching for it produces a lot of rebase Vs merge results.
I’m always puzzled when people say than git is hard, confusing etc. Is English hard to learn? Russian? Chinese? It depends, as always.
Yep, it’s a learning curve, and as deeper understanding comes, in more ways you start bending this great tool (git).
There is an endless ocean of toolings, helpers etc of all kinds, for all levels.
I’m not saying git is the best. There is no the best tooling in general. Fossil is great, git is great, and some other VCS. Pros and cons are everywhere.
git is a battle tested software. Who argues?
Yep, it’s a learning curve, and as deeper understanding comes, in more ways you start bending this great tool (git).
There is an endless ocean of toolings, helpers etc of all kinds, for all levels.
I’m not saying git is the best. There is no the best tooling in general. Fossil is great, git is great, and some other VCS. Pros and cons are everywhere.
git is a battle tested software. Who argues?
> on a similar note, it would be nice to be able to have multiple authors in a commit message. it's one of the few times in git that there's only one of a thing allowed.
I mean that's just not true.
https://docs.github.com/en/pull-requests/committing-changes-...
I mean that's just not true.
https://docs.github.com/en/pull-requests/committing-changes-...
The point tef is making is that a commit header can only have one Author: field. If you want more than one author you have to work around git’s design limitation using ad-hoc trailer fields as described by your link.
There are so many things to dislike about git, but I feel like so much of this post is reaching for cause to be offended.
Sha1 is a hashing function. As a hashing function, it's fine. Why does your identifier need to be cryptographically secure?
I agree with the name and email issues, but laughed at the ideal that a URL is somehow more robust.
Who claims that git is a database?
I agree with the broad strokes, especially having as many conversations as I've had with frustrated people about why their repo is in an unhappy state.
Sha1 is a hashing function. As a hashing function, it's fine. Why does your identifier need to be cryptographically secure?
I agree with the name and email issues, but laughed at the ideal that a URL is somehow more robust.
Who claims that git is a database?
I agree with the broad strokes, especially having as many conversations as I've had with frustrated people about why their repo is in an unhappy state.
> Why does your identifier need to be cryptographically secure?
There are many use cases where people are using the hash to guarantee no actor has inserted different code than they expect in a dependency, so the dependency is pinned to a hash. Not being secure, would be catastrophic for some use cases that people are currently using if widespread.
We could make a claim this is a misuse, but this is what people are doing.
There are many use cases where people are using the hash to guarantee no actor has inserted different code than they expect in a dependency, so the dependency is pinned to a hash. Not being secure, would be catastrophic for some use cases that people are currently using if widespread.
We could make a claim this is a misuse, but this is what people are doing.
Git was using SHA1 as a cryptographically secure identifier right from the very first month of its existence. https://github.com/git/git/commit/65f0d0ee4627dd0f0468ceded3...
The first time I tried to use git, I shredded my repo trying to revert an edited file.
Yeah I've had similar experiences. I can make my way around git just fine now, but the learning curve was not pleasant. Git is one of my two perennial examples of "why programmers should not be allowed to design UIs, because they suck at it" (the other being vi).
Are there other free (like payment) alternatives to git?
The only other one I know of that can be used for large files is https://www.plasticscm.com/ .
The only other one I know of that can be used for large files is https://www.plasticscm.com/ .
There's Jujutsu/jj: https://github.com/martinvonz/jj
It can be used with regular Git repos.
It can be used with regular Git repos.
maybe fossil[0]? Not sure about `large files` (and in fact I went to comment to ask about anyone using it 'in production' when I saw your comment)
[0]: https://www.fossil-scm.org/home/doc/trunk/www/index.wiki
[0]: https://www.fossil-scm.org/home/doc/trunk/www/index.wiki
Re. large files: fossil inherits sqlite's limit of 32-bit signed integers for blobs, so 2GB. Fossil's own developers (myself included) have never come anywhere near that limitation in everyday SCM use.
Mercurial is still actively developed.
And its interface makes more sense than Git.
And with sapling, a fork of Mercurial, it is network compatible with git so you can get around git and github's network effect
I wish git would stash changes when I checkout uncommitted code
You can make this happen with a git alias[1].
https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases
https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases
I thought git complains and doesn't allow you to checkout uncommitted code? Something along the lines of 'please commit or stash your changes before checking out'
It does, they wanted an automatic thing to happen. Imo, i would never want this by default. that complaint/warning has saved me a number of times, from breaking other things
You can do it as long as your changes are only to files that are otherwise identical on both ends of the checkout (meaning there's 0 possibility of conflict).
[deleted]
The git authors as UUID suggestion seems good to me. Will that get implemented in git?
Yep, ran into the "don't change your name" edge case. I have the choice of rewriting history and coordinating that amongst team members, dealing with it, or switching companies and never working on the project again.
So far, I just deal with it, even though it chips away at my soul each time it comes up.
So far, I just deal with it, even though it chips away at my soul each time it comes up.
Is there a reason .mailmap doesn't work in your case?
https://git-scm.com/docs/gitmailmap
>If the file .mailmap exists at the toplevel of the repository, or at the location pointed to by the mailmap.file or mailmap.blob configuration options (see git-config[1]), it is used to map author and committer names and email addresses to canonical real names and email addresses.
https://git-scm.com/docs/gitmailmap
>If the file .mailmap exists at the toplevel of the repository, or at the location pointed to by the mailmap.file or mailmap.blob configuration options (see git-config[1]), it is used to map author and committer names and email addresses to canonical real names and email addresses.
Not all git commands consult .mailmap when they should, so it’s a very leaky and incomplete way to address the problem.
> anyway, where we we?
I think it was supposed to be where were we
I think it was supposed to be where were we
Was there some traumatic incident with upper case in the author's past?
"git is made from papercuts"
This pretty much summarises my experience with git.
This pretty much summarises my experience with git.
Seems more like a rant where the author does not even show how he gets himself into the trouble is tries to describe.
Rebase, merge, and submodules being good examples. Show what you are trying to do and it becomes a whole lot easier to understand. Who uses rebase often anyways ?
Poorly written also imo.
Rebase, merge, and submodules being good examples. Show what you are trying to do and it becomes a whole lot easier to understand. Who uses rebase often anyways ?
Poorly written also imo.
I use rebase every day because fix typo commits are not useful and having good commit messages helps a lot with code review
I can understand not using capital letters for short informal messages, but reading whole article written in such style is hard.
That said, I agree with most points. The main problem with Git is that it's not bad, it's good enough. Mercurial and Fossil are superior, but Git is good enough, so people won't switch.
That said, I agree with most points. The main problem with Git is that it's not bad, it's good enough. Mercurial and Fossil are superior, but Git is good enough, so people won't switch.
Fossil seems superior (never used it professionally though), but i did use mercurial, and in practice it's really inferior imho. It isn't much simpler, as my git aliases are with me since 2014, and that make git as simple to use (for me) as mercurial in cli. If i need to work with VSCode, both plugin are as "easy" to learn anyway. Magit is just more efficient (thus easier) for idiots like me that had too much time at school, but i understand this is a bad argument.
But no reflogs and no rebase makes it harder to use branching locally, and branching in general in mercurial isn't as flexible as it is in git (ok, i get it, it is footgun, but an airsoft footgun imho).
But no reflogs and no rebase makes it harder to use branching locally, and branching in general in mercurial isn't as flexible as it is in git (ok, i get it, it is footgun, but an airsoft footgun imho).
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.