6 ms·

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 bee

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.

adhesive_wombat 3y ago
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.
atq2119 3y ago
Thank you for putting my own (~10 years ago) experience with Mercurial into words.
btreecat 3y ago
That's one diff between git and Hg. Hg likes to consider the history "sacred" so there's no "cleaning up your commit" via squashing/cherry picking. This is actually superior in most cases. Being able to force rewrite history so easily in git was a design mistake imo.
- aayjaychan 3y ago
  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. [2]: https://foss.heptapod.net/mercurial/mercurial-devel/-/commits/branch/default https://foss.heptapod.net/mercurial/mercurial-devel/-/commit...
- dahart 3y ago
  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.
nonbirithm 3y ago
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.
naasking 3y ago
> 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?
- dreamcompiler 3y ago
  I'be never understood this either--this idea of revising history to make the log look better. The proper solution is to build a better log display tool, not change the log itself.
  - naasking 3y ago
    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.
  - atq2119 3y ago
    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.
    - dreamcompiler 3y ago
      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.
sedatk 3y ago
> 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.

adhesive_wombat 3y ago

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.

atq2119 3y ago

Thank you for putting my own (~10 years ago) experience with Mercurial into words.

btreecat 3y ago

That's one diff between git and Hg. Hg likes to consider the history "sacred" so there's no "cleaning up your commit" via squashing/cherry picking. This is actually superior in most cases. Being able to force rewrite history so easily in git was a design mistake imo.

aayjaychan 3y ago
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. [2]: https://foss.heptapod.net/mercurial/mercurial-devel/-/commits/branch/default https://foss.heptapod.net/mercurial/mercurial-devel/-/commit...
dahart 3y ago
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.

nonbirithm 3y ago

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.

naasking 3y ago

> 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?

dreamcompiler 3y ago
I'be never understood this either--this idea of revising history to make the log look better. The proper solution is to build a better log display tool, not change the log itself.
- naasking 3y ago
  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.
- atq2119 3y ago
  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.
  - dreamcompiler 3y ago
    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.

sedatk 3y ago

> 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.