Sad to see another Mercurial holdout switch to Git.
The latter is ahead in network effects in a massive way - but I always preferred Mercurial. I'd have used it more but - network effects! - used git because of the projects I was working on.
The main thing was that the mental model of Mercurial fit in my head and the CLI was predictable and regular, whilst the tool still scaled to large codebases.
I find Git wants me to think about its implementation details and internal terminology at unpredictable moments during use. It still gets the job done but it feels like doing random CAPTCHAs in the midst of my work.
Last time I checked every alternative to Git was lacking some major feature that would immediately make it a non-alternative to me. (And I wouldn't even remotely call myself a Git power user.)
For Mercurial, that was shallow clones. I haven't looked at it in a while, but a quick googling shows me a wiki page where they discuss how an implementation could look like, and it hasn't been updated since 2015.
Network effects are certainly a reason git is popular. But also: If you want to challenge git, you should be able to compete with its basic features.
My workflow in Git centers on the index, and making lots of commits on local branches that will never get pushed. I spend a day working, rewrite history, stash a bunch of unrelated changes on temporary branches, and then send a couple commits on the main branch for code review.
When I used Mercurial for work, it felt surreal to have all of those weird little workflows get locked away behind plugins. I get how Mercurial is way easier for people starting out, and I also get that I could just use the plugins, but when I use Git, all those history-rewriting tools are right there where I want them.
Thanks - that looks interesting. It's especially appealing because it seems to add value beyond just being a neater wrapper to the same operations, it looks like it'll enable new ways of working with the tool.
Yeah pour another glass for Mercurial, it is a shame that git ended up winning, but then again what to expect when it was a child of Linux kernel project.
Some arguably* technically superior designs end up being obsoleted over time, because the arguably* inferior design ends up being more lined up with how people think and machines work.
This is what we're seeing here, IMHO.
*: There's nothing "objectively something" in computer science, because it's all is a pile trade-offs to get the desired result.
hg was not superior to git at v1. I have no idea if it is now. hg was horrible at git style branches wich are arguably a killer feature of git. I've heard they were grafted in to hg but you can go look up old tutorials on the net from say 2008 and see they were clearly not the norm for hg
---
looked it up, the feature is called "bookmarks" and was added in 2010. And even after added, all tbe tutorials ignored them. no idea if they are the recommended workflow now but if not then you probably don't get why git is superior to hg
Bookmarks were a wonderful feature and I used them all the time for release workflow. It was basically like tags in docker.
Hg was indeed better than git, especially in the early days. But as git added features, made sane default choices more common, and cleaned up the CLI a bit, it doesn't matter now. They all do roughly the same thing, but the Hg workflow was still better imo because they just worked more intuitively coming from never using any DVCS before.
Git has better performance for a lot of users in a lot of use cases. Git is certainly not always better-performing than Mercurial, but it is often better performing, and the performance differences have varied at different points in time.
Some parts of Mercurial struck me as obviously better than Git, like the overall CLI UX, but some of the differences just seem like differences that come with tradeoffs. Mercurial is somewhat more opinionated about branches and allows some weird scenarios like “branches with multiple heads”, whereas in Git, a branch is just a label for one of the heads in the first place. Git’s index seems to trip up a lot of beginners, but as a long-time Git user, I don’t know how I could live without it.
I can see why people say “subtly superior”, but I think the superiority is overstated. The CLI UX is the only part where it seems like Mercurial has a clear advantage (and maybe better support for large files).
Both Git and Mercurial works on graphs and use very similar structures, however how Mercurial uses this is mentally overloading, while it's very trivial for a computer to handle these.
Mercurial labels everything on the graph. Multiple heads. many branches, a working copy, a tip. Manual merges, mandatory merge revisions, oh my...
Very neat for enabling collaboration, very easy for a computer to handle, very simple to implement, but very hard to process for a human. Also very hard to follow provenance.
How we came here? X merges, Y branches, Z commits, a curvy journey through the graph. An unbounded art which needs time to grasp.
Git is simpler. Divergences are branches. You add commits at the top of that branch. The place you're looking is the head. Simple, more stupid, a more clunky approach which enables many more things.
How we did come here? Branched at X, added n commits, Y merged along the way, m more commits and ta da. Who added these commits and when? A on Monday, B on the weekend. D merged their work on next Tuesday, and I did mine on today at 10.
Want to chop of specific parts off? Possible. Fork from a branch? Possible. These are things mentally easier to visualize. Mercurial can do these too, but it's more work, more mental effort and more complex to visualize.
Mercurial might be a better DVCS for nerds, but Git keeps is simple as possible and gets the job done well. This is why many people prefer it, incl. me.
Fossil is also a good idea with very high mental load. An idea which is searching for a problem, but I digress...
Of all the adjectives used to describe Git, “simple” seems to me the least appropriate.
Yes, the internal Git implementation is a “simple” DAG of content hashes, but the rest of the plumbing leaks so badly into user space you can’t begin to call using Git “simple”.
The usage of Git is not simple for the beginners or advanced scenarios. Even Linus accepts this, and this is why Git is named Git [0].
However, the mental model required by Git is much simpler than Mercurial, or at least designed to be presentable in a much simpler manner, and this counts for many folks, even if these people can work with much more complex mental models.
At the end of the day, our attention span and power is limited.
Hmm, I held onto mercurial for years, feeling that Git was kind of incomprehensible. I have never really lost that feeling, but I can do a lot of things with Git that I never could with Mercurial, and short of anyone solving the ‘merge one patch to multiple different branches without a bunch of conflict resolution’ I don’t think I’m likely to switch.
The superiority of Mercurial works against it, because while https://xkcd.com/1597/ is entirely relatable, people are used to Git's specific flavour of incomprehensibility. It's normal, and the lore helps folk avoid the sharp edges most of the time.
git stores diffs, but the usual operations are between commits, which resolve to a snapshot, yes.
but there are operations that get the diffs (interactive rebase for example)
so, git, in typical UNIX fashion, is a bit of this and that, a very useful collection of tools to work on a repository, under some allegorical unification umbrella.
Layers of abstractions. From the outside, we see diffs (or checked out trees). Looking at the next layer in, every file in every commit is present in the DAG. Then the storage layer deduplicates and packs similar blobs as binary diffs.
It's quite neat, the object DAG is the canonical representation, but we can optimise on one side for efficient storage and on the other side for our preferred visual representation. Both without particularly needing to worry about the canonical representation being an abstraction, as it's quite good at not being a leaky abstraction.
There are, broadly speaking, two ways for a tool to become popular. The first is to be really good, and unfortunately that way doesn't work. The second is to already be popular, and that's where MySQL and Git came from. If git weren't written by Linus Torvalds, I'm sure it wouldn't have become nearly as popular.
Git is, per the XKCD, a really neat graph system. There's not much that's special about that, though. Now it exists, we can write another just like it as a programming tutorial. The UI is better than it used to be, that's pretty much the best that can be said about it. But if you know the magic incantations you need to interact with it, and especially if you're using IDEs, it's really no worse than CVS.
The biggest difference between git and MySQL is that the former is solid underpinnings but poor UI and the latter is poor underpinnings but easy to deploy. In both cases, the foibles are well enough known that most folk don't need to worry about them, and and most projects I've worked on would derive no benefit from switching to a different system that's only going to confuse people.
I say this as someone who appreciates the graph, but has occasionally resorted to invoking plumbing directly because I can't work out which plumbing commands would do what I wanted.
>The latter is ahead in network effects in a massive way - but I always preferred Mercurial. I'd have used it more but - network effects! - used git because of the projects I was working on.
I've recently wrote a post about it - how we're kinda locked with git and how other solutions have it hard to get adoption.
git was good, but github cemented git's position. So unless GitHub allows other solutions, then we're kinda locked.
>So what's the issue here? I'm worried that just because GitHub is so good, then unless they decouple from git as letters management engine and allow any/other, then we will be locked with git.
I totally agree about Mercurial's superior ease of use and simpler mental model. However, it feels quite abandoned. I don't know what caused it though. It's a perfectly viable alternative to Git in my opinion.
Facebook uses a heavily modified fork of Mercurial which they have (as of last year) released publicly, and now refer to it by a new name, "Sapling" (though the command may still be called 'hg' internally). And Sapling actually stores data using Git's on-disk format, along with an entirely bespoke server-side backend. It is an entirely different project from Mercurial, now.
I never understood how people can happily figure out a gigantic, complicated code base like Firefox and are taken aback by learning a little bit about some tool. In your case, was it a thing where working with an unfamiliar tool was simply demotivating? Cause I think if you can write a Firefox patch, you should be able to learn Mercurial during breakfast.
I could resonate with him/her if I were not familiar with Mercurial. Because he/she is aiming to fix or improve Firefox, figuring out a gigantic, complicated code base of Firefox is directly towards his/her end goal. Meanwhile, figuring out hg feels a waste of time.
I didn't need to figure out a gigantic, complicated codebase. I only needed to figure out devtools frontend which is a significantly smaller portion of it and relatively self-contained.
For the same reason I get frustrated when I go to solve problem A, run into problem B then while trying to solve problem B I run into problem C. Soon enough you have 15 problems you want solved but you find yourself having to unwind a stack 1 by 1 until you _finally_ get to a point where you can actually solve the original problem.
People probably view dealing with the FF codebase as part of Problem A, dealing with mercurial is Problem B, which is must less appreciated.
Speaking for myself, coming from git, I found the branching model of Mercurial hard to understand. Then it turns out that instead of branches I should have been using "bookmarks"? But which to use when?
I tried to work on a Mercurial-based project (not firefox) but eventually gave up and just used git to track my changes and then prepare, very carefully, specific big merged commits to contribute back. It was easier, because I could never figure out how to clean up properly if I made a mistake -- so this way, I could just wipe the local copy and start over instead. But it was annoying, and I was glad to stop using it.
Completely bewildered by every thread about mercurial full of people proclaiming its advantages and "simpler mental model". Simpler than a DAG with pointers? Sure.
If I remember correctly you even needed to install some kind of external plugin just to do simple rebasing / branch cleanup. Now's the part where you tell me I'm doing it wrong, shouldn't be rebasing etc etc, but I'm just saying, it didn't work for me; and the constant claims that it's somehow objectively "better" but misunderstood get really boring.
The thing about git is that while it does leak the implementation a bit and some of the CLI commands show their history of its emergency cobbling-together, it supports many many workflows equally well. At the expense of not having one completely gleamingly-simple happy path as a first-class citizen. It's a bit like C in that respect, which isn't especially surprising considering the inventor.
Published history in Mercurial is sacred [1]. Modern Mercurial fully embraces history editing, and provides (IMO) better tools than git to facilitate (safe, collaborative) history editing.
[1] You can still change published history if you try hard enough with a lot of co-ordination.
If Mercurial doesn't support cleaning up of commits, then the commit history of Mercurial itself [2] wouldn't look so clean.
Why? What need is there to preserve the commit history, and why is it superior? Are you very familiar with git and understand what workflows the git history rewriting tools were intended for, and how they’re typically used and supposed to be used?
Git only ever advocated for rebase, squash, and cherry pick for local branches that haven’t been pushed or shared yet. It is arguably not even “history” until you publish it. There have always been strong warnings about doing those things to published histories. It’s bad form generally speaking to do it (rebase or change history) to a published branch that more than 1 person is using for any other reason than extreme necessity, such as cleaning up security accidents where someone pushed keys or info they weren’t supposed to. And for exactly that reason, all the opinionated DVCSs that claim to consider history “sacred” actually offer the ability to easily rewrite published history, including Hg and Fossil!
Git’s ability to rewrite local history is pretty important for (1) encouraging a commit-early commit-often workflow where the local repo is a safe space, (2) cleaning up your work to make it presentable and semantically organized before sharing/publishing, and (3) allowing real-world workflows where people didn’t plan every single feature branch in advance but happened to end up working on multiple things and committing them first.
A version control system should be, first and foremost, a safety net that simply backs up any work you do without judgement. Personally, I consider the idea that commit history is sacred to be dogmatic and unnecessary. I’m open to the idea that it might help prevent a few specific types of accidents here and there, and it might be fair to argue that offering tools to groom the history’s presentation, separately from the log of commit activity, is on average a slightly better idea than having to actually reorganize commits before pushing them. Maybe that didn’t occur to git devs before it was released, or maybe it did and they decided it wasn’t going to help anyone and just add confusion to have two separate timelines. I don’t see any reasons justifying calling git’s design a ‘mistake’, and there seems to be evidence that most people are fine with git, and that for whatever reason the DVCSs that reacted to git in 2005 by immediately trying to fix some of git’s perceived issues didn’t ultimately fix the problem well enough to gain traction.
> Why? What need is there to preserve the commit history, and why is it superior?
Being able to lie about what changes took place, what methods might have been tried by scrapped, and other small things possibly considered "noise at the time" often end up being valuable clues during maintaining that code years later.
>Are you very familiar with git and understand what workflows the git history rewriting tools were intended for, and how they’re typically used and supposed to be used?
Yes, intention for the tools, and the way people end up using them are not 1:1.
The potential for mistakes and information hiding is higher when you can rewrite history.
> Git only ever advocated for rebase, squash, and cherry pick for local branches that haven’t been pushed or shared yet.
Just because they advocate using it the right way, they enable using it the wrong way so people will use it the wrong way, and that's a guarantee of humans.
>It is arguably not even “history” until you publish it.
If you committed it, it's history.
If you're trying to make the claim of local history having no utility, thats a different argument imo.
> There have always been strong warnings about doing those things to published histories. It’s bad form generally speaking to do it (rebase or change history) to a published branch that more than 1 person is using for any other reason than extreme necessity, such as cleaning up security accidents where someone pushed keys or info they weren’t supposed to. And for exactly that reason, all the opinionated DVCSs that claim to consider history “sacred” actually offer the ability to easily rewrite published history, including Hg and Fossil!
This shows your lack of knowledge and XP with other DVCS and your assumptions there.
> Git’s ability to rewrite local history is pretty important for (1) encouraging a commit-early commit-often workflow where the local repo is a safe space,
No, I can do that with out rebase or cherry pick.
(2) cleaning up your work to make it presentable and semantically organized before sharing/publishing, and
Bad practice. Your history is useful metadata about what happened. I don't want a single commit in your PR. I want to see the reason it took X days.
(3) allowing real-world workflows where people didn’t plan every single feature branch in advance but happened to end up working on multiple things and committing them first.
>
That's a nonsense claim.
> A version control system should be, first and foremost, a safety net that simply backs up any work you do without judgement.
Then use Dropbox?
>Personally, I consider the idea that commit history is sacred to be dogmatic and unnecessary.
I think this shows a lack of XP in maintaining older systems.
>I’m open to the idea that it might help prevent a few specific types of accidents here and there, and it might be fair to argue that offering tools to groom the history’s presentation, separately from the log of commit activity, is on average a slightly better idea than having to actually reorganize commits before pushing them. Maybe that didn’t occur to git devs before it was released, or maybe it did and they decided it wasn’t going to help anyone and just add confusion to have two separate timelines. I don’t see any reasons justifying calling git’s design a ‘mistake’, and there seems to be evidence that most people are fine with git, and that for whatever reason the DVCSs that reacted to git in 2005 by immediately trying to fix some of git’s perceived issues didn’t ultimately fix the problem well enough to gain traction.
Yes, history grooming is purely something for a UI to do.
You’ve lost me from the start, this is 100% bad faith argument. This is against HN guidelines too, the mods have confirmed that parroting Dr. Hipp’s hyperbole is not welcome here. The irony is that calling it a “lie” is pure hypocrisy on your part. You already know that rebase wasn’t invented for the purposes of deceiving anyone, and you’re already aware that nobody using git is under the impression that commits won’t get rearranged (rebase is proof of that), nobody is expecting git commit dependencies to represent the historical order events happened in, because that’s not the way git works and not what it was designed to do, which means you are the one lying here. If you don’t know or can’t talk about git’s design in terms of what git designers were actually intending, then Chesterton’s Fence, you don’t get to tear it down.
What’s so sad about this is you and other Fossil followers are stuck on the bogus bad faith argument, lowering yourselves to attacking and name-calling, when a good faith argument exists and is just waiting for you to adopt it. You don’t have to repeat this stupid hyperbole. There are good reasons to consider other DVCS designs. There are ways to talk about and justify and sell what Hg and Fossil do without trying to villainize git and git users. For your own sake, and for the sake of setting a better example for other Fossil fans, try to find the strength to shed yourself of the negativity and explain why other systems are better than git while maintaining the stance that git was a good design for it’s time. If you can’t do that, then seriously, consider the possibility that the thing you’re arguing over actually isn’t better.
while I'm not a fan of rebase, I don't think it's a design mistake of git. I do think it's a dangerous tool used entirely too cavalierly by a lot of developers.
It's like using an ORM as an abstraction. Someone could build an ORM that took a hard stance that raw SQL should never, ever be used. Such a tool is less useful than an ORM that allows raw SQL but encourages the use of the ORM's facilities instead.
> Then it turns out that instead of branches I should have been using "bookmarks"? But which to use when?
We've been using Mercurial branches for more than a decade like Git branches. What specific problems did you have with Mercurial branches? I've never used bookmarks with Mercurial.
> I could never figure out how to clean up properly if I made a mistake
Interesting because that's my biggest problem with Git. In Mercurial, it's just about learning the meaning of the distinct terms like "rollback", "revert" and "backout". In Git, you must know the many cryptic variants of "git reset" instead.
> Simpler than a DAG with pointers? Sure.
I don't how Git's DAG different than Mercurial DAG from a user's point of view. In my opinion, Git's mutable by default semantics and staging area adds unnecessary complexity for a beginner. That's what I mean by simpler.
> If I remember correctly you even needed to install some kind of external plugin just to do simple rebasing / branch cleanup.
They're all built-in but opt-in features called "internal extensions". Maybe, you're referring to early versions of Mercurial from 15 years ago or so when they were external.
> Now's the part where you tell me I'm doing it wrong, shouldn't be rebasing etc
I use history editing, MQ, rebase daily. I find them handy. But they can be confusing for beginners, so I also understand why they're disabled by default.
> and the constant claims that it's somehow objectively "better" but misunderstood get really boring.
It's impossible to compare two DVCS's objectively other than performance for certain scenarios. But, as a person who uses both daily, I find Mercurial much easier to use, yes.
> It was easier, because I could never figure out how to clean up properly if I made a mistake
Made a mistake doing what? A mistake in your code or a mistake using Mercurial?
> If I remember correctly you even needed to install some kind of external plugin just to do simple rebasing / branch cleanup. Now's the part where you tell me I'm doing it wrong, shouldn't be rebasing etc etc, but I'm just saying, it didn't work for me
I've never understood this impulse to do "branch cleanup". Why are you adding unnecessary work? Is the source repository for tracking a history of changes or is it an art exhibition?
> I've never understood this impulse to do "branch cleanup". Why are you adding unnecessary work? Is the source repository for tracking a history of changes or is it an art exhibition?
The history is an end product intended to help others (often future me) figure out when and why things changed, preferably in self-contained, well organized steps. Often my first attempt at a change does something in an illogical order, or I make related changes that later end up in a separate merge. In the short term that change in thinking is somewhat interesting. In the long term it only confuses whoever is looking through the history to figure out why something is the way it is.
The stronger version of this completely discards any history when merging a feature, but I often find that to get rid of useful information.
> The Git documentation acknowledges this fact (in so many words) and justifies it by saying "rebasing makes for a cleaner history." I read that sentence as a tacit admission that the Git history display capabilities are weak and need active assistance from the user to keep things manageable. Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying, but retain the option to show the real, complete, messy history for cases where detail and accuracy are more important.
I find this take interesting, and I agree with a lot of it. There are also a few things I don't agree with.
Points 1 to 4 argue against the idea of rebasing as an alternative to merging. I agree with this to some extent, but in practice I notice that the exact point at which a branch began is rarely important. A very rough heuristic for this is "can it be rebased non-interactively?". This effectively means I like "cherry-pick merges", and it would be cool if Git remembered more about the origins of them. Rebases that do require manual adjustment are far more error-prone than merges, and I try to avoid those.
Point 5 and 6.0 are the primary reason I edit history. I want my history to tell a coherent story, not just in commit messages but also in the changes themselves, and that story often doesn't perfectly match the actual road traveled to get to the end. I don't much value mistakes where I forgot to implement half a change while tired at the end of a long workday, or an ill-considered false start. Where such information is valuable I'll write it down in the commit messages of changes that implement what did end up happening.
That brings me to the other points. I very much agree with 6.1 and beyond. Squashing branches removes a lot of valuable information, and it removes the ability to tell that coherent story. In particular:
- There are often small changes or bug fixes that aren't really part of the set of changes, but that just happen to become most relevant while developing this feature. Depending on the specifics these could be merged separately, and I keep them separate.
- Nuances discovered later in the development of a set of changes tend to offer valuable insight, so I want to keep them separate from the rest.
It would be cool if Git remembered more of the specifics of how the end result was reached, but I'm not sure if I would use it much in practice.
Small "cleanup" changes required after merging a larger change are often very educational. They highlight subtle nuances in the code that were not thought of when the large change was merged. If the smaller changes were rebased to make one large commit, the edge-case history is also lost.
I completely agree, which is why I'm not a fan of squash merges that remove such nuance. In practice a feature branch often ends up with roughly three sets of changes:
1. Some small commits in preparation for the bigger change, that are also desirable should the rest never end up being merged
2. The big set of changes, either in one big commit or in a handful of smaller, independent commits
3. Some (usually smaller) commits that reflect nuances thought of or discovered after the biggest batch of changes was made
Most of my history cleanup serves to separate part 1 and 2 and to turn part 2 into a set of coherent steps.
Depending on how things go each of these might be merged independently or all at once.
> The history is an end product intended to help others (often future me) figure out when and why things changed, preferably in self-contained, well organized steps.
Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either.
> In the long term it only confuses whoever is looking through the history to figure out why something is the way it is.
Source control is the wrong tool for this job, that's what comments and tickets are for. Source control can help you retroactively figure out how and sometimes why something evolved in a certain way, like a good archaeological tool, but we don't use crude tools when there are better tools.
I've taken to literally embedding ticket numbers along with comments directly in the code and in commit comments to document exactly why code does what it does. All functional changes are tied to tickets [1], and the tickets contain the full context, and the code comments contain a summary of that rationale. Use the right tool for the job.
[1] where "functional changes" means changes that can affect behaviour, rather than stylistic changes on variable naming or revising comments that have no visible effects.
> Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either.
It won't ever be perfect, but that doesn't mean we shouldn't strive to get as close as possible.
> Source control is the wrong tool for this job, that's what comments and tickets are for.
I agree that code comments play an important part in explaining why something is the way it is. Code comments and commit messages play a different role there, but they overlap and it can be tough to balance. Roughly: commits explain changes and the decisions made to arrive at that set of changes. Comments explain the end result and the decisions relevant to explain that end result.
I disagree that tickets are a better way to convey this information. Embedding references to tickets is not necessarily a bad thing, but the lifetimes of issue trackers and source code history tends to be different, so all relevant information from such references should be in the comments or commit messages.
> Roughly: commits explain changes and the decisions made to arrive at that set of changes. Comments explain the end result and the decisions relevant to explain that end result.
Agreed. So a linear history doesn't seem of much use if your current code is well documented, so are all of those pushing for linear history just poor at documentation?
> Embedding references to tickets is not necessarily a bad thing, but the lifetimes of issue trackers and source code history tends to be different
This is why Fossil ties the ticket system along with the VCS all in one system. In the end, I think the ticket system is almost as valuable as the source code, and shouldn't be causally tossed out.
A better log display tool could help depending on why they want the log to look better. I often find that the reasons they want a better log is because they're not documenting/commenting their code sufficiently to figure out the code currently looks the way it does, so they want their source control to make up for poor coding practices.
I would certainly like to see this mythical tool that can support both:
* Separating out different conceptual changes that are/were reviewed together and
* Transparently cleanup a messy history that starts with a few base commits (corresponding to the conceptual changes) followed by a bunch of fixup commits for issues found by CI and review.
That is the main problem solved by rebasing. I have yet to see even a coherent proposal for what the alternative would look like.
This is yet another article that doesn't really seem to get it. For example: it argues that many small check-ins are better for bisecting -- but enabling a development process that encourages many small commits while still allowing bisect to work is one of the big reasons of rebase's existence! (Perhaps the author is biased/doesn't understand common use cases because SQLite has a famously thorough test suite that almost nobody else comes close to. SQLite's development flow is also comparatively simple: the Linux kernel, for example, has orders of magnitude more developers.)
That said, it gets quite close to an interesting idea here:
> Second, if Git remembered the source of cherry-picks in commits, Git users might have a better argument for avoiding rebase, because they’d have an alternative that didn’t lose history.
I like the idea of properly remembering cherry-pick sources in commit metadata. It would be a cool thing to have, and potentially sometimes useful.
But try to really imagine a world where this is how Git worked. How would you solve the two problems I stated in my GP comment? You'd just transform state A of a branch into state B by performing a sequence of cherry-picks. And that's pretty much exactly what git rebase is...
So no, the author's proposal wouldn't eliminate the need for the rebase flow. It would subtly change the result of a rebase in a way that preserves more history. Which may or may not be useful, but I mostly wouldn't mind it.
(Just for your consideration, losing history can be important when you're maintaining a mixture of open and closed source / trade secret branches. You may not care personally, but being pragmatic about such things has certainly helped git.)
> Perhaps the author is biased/doesn't understand common use cases because SQLite has a famously thorough test suite that almost nobody else comes close to
I'm sure they understand the use cases quite well, and designed their Fossil VCS to address these faults.
> And that's pretty much exactly what git rebase is...
Except rebase disconnects it from the history where the author's solution does not. A view on a SQL table does not change the underlying data, it just presents it differently. That's the difference between what the author's proposal and yours.
This could work with "meta-commit" messages added to groups of commits after the fact. Such messages could be parsed by the log display program. Git notes is the obvious tool for adding such metadata.
My brief experience was largely the same. A disproportionate amount of time trying not to lose all my work and having to checkout again and then trying to use Git on top of it which failed. I only went back to trying to contribute patches when BitBucket sunset Mercurial and the maintainers had to switch to Git.
I also find mercurial vastly more pleasant to use - nowadays I’m mostly using Sapling, since that’s basically mercurial’s frontend with the ability to speak the git protocol to git servers :)
Say you dislike one peace of software because it does not have your used to mental model? okay sounds reasonable.
Mercuiral booksmarks are strange to me and dont fit my mental model. Its like finding a bookmark for an article in my bookmark manger that I stored in some folder. So Random
I think one thing that helped git early on was that its concept of branches were just really convenient.
For me I'd say it's that git doesn't fit my mental model and Mercurial does - it's that mercurial gave me a smaller mental model that (at least back when I used it heavily) allowed me to do what I needed.
Even as a fairly experienced and advanced Git user, Git requires me to keep more state in the head and at, from my point of view, unpredictable times needs me to extend the model. The strange thing is that this is despite having a very simple model at the lowest levels of the system.
The latter is ahead in network effects in a massive way - but I always preferred Mercurial. I'd have used it more but - network effects! - used git because of the projects I was working on.
The main thing was that the mental model of Mercurial fit in my head and the CLI was predictable and regular, whilst the tool still scaled to large codebases.
I find Git wants me to think about its implementation details and internal terminology at unpredictable moments during use. It still gets the job done but it feels like doing random CAPTCHAs in the midst of my work.