Could you elaborate on what these things are and why you disagree with them?
> The Sapling CLI, sl, was originally based on Mercurial, and shares various aspects of the UI and features of Mercurial.
It's a pet peeve of mine folks that use python subprocess as a replacement for bash because it takes special discipline to not eat stdout and stderr, or to correctly try:finally: to show the Proc details before the raise eats the variable
For example, I use Mercurial’s absorb command [1] and was pleased to see it in Sapling.
Overall this looks promising.
[1]: https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-ch...
https://lobste.rs/s/nws1uj/help_us_name_new_mercurial_featur...
Will try `git-absorb`.
Hard to discover and remember but once you do it usually works smoothly.
https://github.com/keis/git-fixup
git-fixup will add fixup! commits, so it still needs the mentioned 'git rebase -i --autosquash' afterwards. Usually you do not even need to give it a specific commit if your branch is set to track an upstream branch.
Staged changes, excluding renames.
So git-fixup and git-absorb will now happily live together for the moment on my box.
Made a good first impression, thanks again for the reference.
(My other two posts in this thread are -4 and +7 even though they both say the same thing. I will proceed to ignore this feedback.)
Yes, I read the manual for git, but I never needed to for Mercurial.
1) tfs: shelves are named and can be worked with independently; git: stashes are numbered in a sort of a stack and only the top stash is unpacked and deleted destroying your data, infuriating, also local edits are moved into the stash, not copied.
2) tfs: branches are mapped to different folders and can be worked on simultaneously; git: branches are mapped to single folder and switching branches deletes local edits.
3) tfs: pulling from server merges new text preserving local changes; git: pull and checkout deletes local changes.
4) tfs: can't commit unresolved merge conflicts; git: commits just fine, it's also not obvious if you have merge conflicts to commit or not.
5) tfs: handles concurrent edits as merge conflicts and handles them as they occur; git: you create feature branches and in case of concurrent branches you have merge conflicts when you merge to master, then you have p.4. Feature branches are advertised as a big fat killer feature of git, but I don't quite see the win here, you still have merge conflicts.
6) tfs: all commits in a branch are visible, it's not obvious how to delete them, you can only create rollback commits; git: if something happens to the branch label, the commits are gone.
I don't think your comparison makes sense. Git stash is a way to quickly get to a clean local workspace that can be reversed as you see fit. You use local branches to track independent work.
> tfs: can't commit unresolved merge conflicts; git: commits just fine
Again, this doesn't make sense. In git, users determine whether a conflict is resolved or not. If you commit a changeset originating from a merge conflict, you have to explicitly state that the conflict was resolved and your changes are good.
> Feature branches are advertised as a big fat killer feature of git, but I don't quite see the win here, you still have merge conflicts.
Honestly I didn't understood what point you tried to make. Merge conflicts happen because multiple sources of change touch the same document region in a way that can't be resolved automatically, thus needing human intervention. To the best of my knowledge, there is no cvs in the world that eliminates merge conflicts.
Regarding Git's support for feature branches, the fact that you don't understand the big win Git brought to the world with it's branching model is already a testament to how groundbreaking Git was at the time, and how everyone around was quick to roll out Git clones that follow the same approach. To see what I mean, spend a day working with a SVN repository trying to do work involving feature branches.
> git: if something happens to the branch label, the commits are gone.
Aren't you actually saying that if you delete a branch then the branch is deleted?
Local branches store immutable state, but shelves can be unpacked anywhere (like a stash), thus local changes carry over, but git deletes them on every occasion.
The entire CLI is badly designed, with highly non-orthogonal commands interacting in unexpected ways. Recent versions of git has started introducing commands with a more top-down design (e.g. git switch), but that's a very novel development
Git also diverged significantly from the SVN command line, but instead of following the tasteful Darcs path of making commands clearer and cleaner it commonly:
- reused the same terms for different operations, usually less intuitive ones (e.g. the absolutely awful "git revert")
- removed clear commands to confusingly tack them onto others (e.g. "git add" to resolve commits)\
On that front, mercurial extended the existing commands-set much more cleanly and clearly.
Mercurial's CLI felt like an improved extension of SVN's, Darcs felt like a drastically different take with plenty for it, Git's felt like one of those ransom letters cut out of newspapers, full of jangly bits which make little sense, and concepts which worked fine altered for no perceivable reason.
Isn't git switch syntactic sugar for git checkout? What's wrong with checking out a branch?
The fact, e.g., that it's a completely different operation than checking out a single file or folder? (One changes HEAD, one doesn't. One warns about overriding local changes, one doesn't, etc.)
I want my VCS to be quiet, out of sight and do as it's told, because my main focus should be programming, not how to tame a tool that's supposed to save text. The fact that you have to "learn git", and that there are so many StackOverflow git question on how to do (what should be) trivial operations is probably a hint that things aren't great in the usability department.
For hg, I just read an introductory guide (I think it was Joel Spolski's one) and that was enough. I used to be able to do a more in-depth comparison and criticism but nowadays I use git and try not to think about it too much.
I see this claim often, but it never is accompanied by evidence or any concrete example.
I've been using Git for years and I never noticed any semblance of unintuitiveness or bad defaults. Everything in the happy path is straight-forward, and all obscure things are a quick googling away.
Do you actually have any concrete example to back your claims? What's the absolute best example you can come up with of said unintuitiveness and unfriendliness?
We've had dozens of discussions about this here on HN – with lots of evidence and concrete examples.
https://www.google.com/search?q=git+user+experience+site%3An...
Just compare the man pages! "git help clone" vs "hg help clone".
A random (trivial) example off the top of my head. When working with branches:
> git pull
> git switch another-branch
Your branch is behind 'origin/another-branch' by 2 commits, and can be fast-forwarded. (use "git pull" to update your local branch)
... why? I literally just pulled, why are you asking me to pull again? 99% of the people on the planet literally want the last version of that branch (provided there's no local changes leading to a conflict).
Compare with hg:
> hg pull
> hg update another-branch
Done.
I haven't worked with hg in a long time so I can't really provide an "absolute best example". All I can say is that, from memory, hg always got out of the way, and when I wanted to do something out of the ordinary I could either guess how to do it or it was easy to figure out from the manual.
With git, almost nothing's easy. It can become easy if you invest a lot of time in understanding how it works internally (which explains some of its CLI choices). But that to me is a sign of a bad tool. "all obscure things are a quick googling away" - why expose the user to obscure things to begin with?
I feel like the Mercurial fanbase is just another loud fanbase. I did start with CVS and SVN and git was absolutely fantastic when I started using it. On the other hand I could never get the hang of Mercurial. From MY PERSONAL perspective it has a terrible UX(which is the exact opposite experience of the loud hg fan git critics on HN). I absolutely cannot relate to the people who say that Mercurial has the better UX, but I don't remember myself constantly bashing mercurial either like the other side does. From my perspective `git add -p` is an important essential functionality that hg does not provide. I believe there was some sort of plugin but it was no where near as polished.
Yes, there are a handful of nice features in mercurial, but none which are actually necessarily needed inside of the git core.
I do faintly remember that my biggest problem with git was understanding that a commit doesn't push automatically. But then again that's just a difference between a DVCS and whatever was there before.
Mercurial has an interactive commit mode (hg ci -i) with a slick TUI for navigating and selecting chunks to commit.
Users that started with Git are more likely to internalize Git's concepts as "the natural way to do version control", and more likely to find Mercurial counterintuitive.
I'm not saying mercurial is better, but there's a reason I have to remind people that this[1] is satire - the real manuals are so convoluted that they seem like parodies of themselves.
[1] https://git-man-page-generator.lokaltog.net/#c2NyZWVuJCRnYXJ...
But where mercurial shines with a clean, consistent and simple UX, git is a mess where storage-layer abstractions leak to the user and where single commands serve multiple unrelated purposes.
To give you a practical example, any command that takes commit(s) as argument (for checking-out, logging, rebasing, …) would be passed a `revset` in mercurial-land. Revsets are a simple DSL to address commits (by hash, lineage, topology, distance, …), which makes new commands easy to learn, and renders one third of `git help log` inadequate. Most commands that output something use templates as argument, which renders another half of `git help log` laughable.
There is nothing "natural" about the git UX, you've got to accept that it grew organically with no attention to details.
All this to say, I love git, and as a versioning system, it seems obvious to me that we can do better than git for 90% of workflows. Just yesterday I was surprised by how `git push --tags` worked and had to read the man page for `git-push` to see I wanted `git push --follow-tags`. Just reading this forum today I see that I alternately probably(?) could have figured out what I wanted with `git help push` which I didn’t even really realize was a thing.
But do I want to use an easier versioning system? I’m not sure. git has a kind of forcing function for a growth mindset. I value it for its creative expressivity.
Edit for sibling comment: Stockholm Syndrome, quite possibly. But as the “victim,” I still love git!
That's not to downplay git qualities, but as a social experiment in soft peer-pressure and group-thinking, I think it has value (though that's beyond my field of expertise).
I came to mercurial when, after shooting myself in the foot with git for the N-th time and going on a rant about it, someone on IRC told me to give mercurial a shot and move on with my life. I confess that TortoiseHG helped me translate my git habits into the equivalent hg commands, and the kind of history exploration that I was doing then set me up to speed with the revset way.
Then, what I found formidable was that all the knowledge about git intricacies that I had accrued and internalized with pride over the years became absolute no-brainers and irrelevant in the hg world: I remember a famous stackoverflow thread in 10 steps for merging two unrelated repos (including arcane git commands, shelling-out to sed, and non-transactional storage-level ops that would warrant a backup, as was the norm back then). How do you get history from a repo in hg? `hg pull`. How would you go about getting history from a repo (unrelated) in hg? `hg pull` as well. And thinking about it, would have git been nicely designed, it wouldn't have had to care about the difference and even less so had to expose it to the user.
Mercurial, although not perfect, really opened my eyes on what good UX design should look like.
I have used (actually introduced) Mercurial before at a company and considered them basically equivalent enough, only to get stuck in some horrible design choices of early Mercurial (named branches and not having rebase by default). I am happy to see these elements corrected in Sapling, giving me enough confidence that I might actually use Sapling over time...
I wish it had won the DVCS wars.
Seems to be a recurring pattern when people interact with open source communities. Why does it have to be like this? It's not just companies either...
Because motivated, high performing people need to have control over their own destiny. Because cookie-cutter solutions which work for 90% of use cases are often worse than something explicitly tuned for you.
People having specific needs, getting frustrated and then solving their problem is a feature of opensource code. Its not a bug. It is the engine of innovation and improvement. Forking means we can both get what we want, even if our needs are contradictory or we don't want to work together.
This happens with commercial offerings too - but its a mess. You can't just fork the code without paying (or sometimes at all). And every fork is private, so work is duplicated and collective learning doesn't happen. Expensive consulting-ware might be the best case outcome.
The ability of motivated people to fork projects and have their own spin on things is one of the biggest strengths of opensource. May the best forks win.
This opinion seems to be peculiar to software and I think it has something to do with the fact that software is one of the few verticals where you can (attempt to) intellectualize everything.
Having control over your own destiny in any other skilled labor job seems to be 98% about finding a brand and model of tool that works the way you do, and 2% building your own tools or jigs for that specialty task nobody thought to build a tool for.
In software it's anywhere from 90:10 to 10:90 depending on how much emotional baggage your coworkers are carrying around.
I don't quite buy this: Those same "motivated, high performing people" don't seem to have anywhere near the same "need to have control over their own destiny" when it comes to the commercial closed-source tools they use.
I’ve seen people reinvent the wheel all over the place because their tools weren’t quite working for them. This instinct is the reason most good software has APIs - so you don’t have to ditch the tool entirely to customise it to your workflow. And most medium to large companies have all sorts of wacky customisations on top of existing software.
Eg perforce at Google. Well, everything at Google. And a friend at a big broadcaster has a bunch of company specific plugins for Reaper for their audio editing pipeline. And everyone insists on customising Jira.
I'm certainly in that camp; and it pains me every time I have to use the hggit extension to convert a mercurial repo to git in order to work with everyone else...
hg init
git init --bare
common problem in open source. any project that gets big enough effectively stops anyone from wanting to work on an alternative, or use an alternative, due to the momentum of the large project.
deviating from it makes it harder to collaborate or be productive because the big project does everything (though often poorly), everyone knows it already, and no one wants to learn something new, and no one wants to work with the people using the weird thing.
same reason why it's hard to make a Facebook alternative.
Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive.
We peer-pressured ourselves into collectively using a less-than-ideal tech because that was the price to pay to belong.
That's completely made up on your end. I've been doing FOSS for 17 years and the vast majority of people were barely competent with any of them at all beyond whatever their chosen ponyshow was (including off-brand ones like Darcs and Monotone), and any switching from a persons preferred one to the use of another project was often met with grunting and complaining, if it was done at all.
The reality is we only think this because we saw people do this, at great cost of their own time -- but that's the literal definition of survivalship bias. For every 1 person doing this 50 just stuck with whatever they used and wouldn't bother. I've literally seen people refuse to contribute to a project over tabs vs spaces, and people still do this with git vs hg today, just not as much today.
More people use Git and contribute to FOSS in a single day in 2022 than every developer who knew all these tools combined back in 2008 or whatever. Whether this is good or bad is up to you, but you don't need to make up claims about developers being epic journeymen in the past and mastering 50 version control tools to do a single days work. They did not.
> Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive.
Sorry, but I consider this to be a similarly made up claim that's just sour grapes. I've been using GitHub since 2008, I'm one of the first users. GitHub didn't even have "gamified" social features until the past 3-4 years IME (what, stars are about it?), and before that its product was pretty poor in some key areas like code review and project management, org permissions, on-prem control, etc. I didn't even use GitHub commercially until like, 2018, because most orgs had setups that were better in some key areas. But it was pretty easy to use and get started with, which mattered, and still matters, and soon enough nobody could compete with the same ease of use for free projects.
If I had to "blame" "someone" in this vein, a better place to start: global monetary and fiscal policy for the past 20 years resulting in software development becoming one of the only places with rising wages to meet cost of living demands in places like the US -- resulting in an influx of new blood to increase their wages and quality of life, combined with political choices like low interest rates, and huge explosions in demand for software devs for things like VC adventures, etc. Subsequent developments like bootcamps designed to churn devs out to match rising demand, etc which solidified platforms like GitHub further as it was easier for them to paper over these fundamentals when there was a clear winner (git/github) to focus on and ignore everything else. Forest vs trees and all.
> That's completely made up on your end. I've been doing FOSS for 17 years and the vast majority of people were barely competent with any of them at all beyond whatever their chosen ponyshow was
I doubt either of us has actual figures, so it's "my experience" vs "yours" (and full of anecdotal bias which I'm willing to admit). At least what's factual is that a decade ago, the versoning and tooling ecosystem was much more diverse: where today github/-actions/-CI/-issues/… is a quasi-monopoly you would bump into a new hosting solution/bug-tracking, reviews and CA build systems every other week, and the major open-source projects were either using CVS, SVN, GIT or HG. So, in proportions, more people had to be able to switch from a system to another, just out of practical considerations.
And I'm not even looking back pretending that things were perfect back then, I'm only suggesting that the monoculture which ensued killed a lot of competition, innovation and convenience, from which we could benefit today, on top of increased standardization (did you know for instance that hg can pull and push to git?)
> For every 1 person doing this 50 just stuck with whatever they used and wouldn't bother. I've literally seen people refuse to contribute to a project over tabs vs spaces, and people still do this with git vs hg today, just not as much today.
There's some truth to that, but it's a pretty extreme view. All projects can benefit from a lower entry bar and should be as welcoming as feasible, but optimizing for drive-by contributions at the expense of more meaningful involvement is destructive on the long run: anyone having worked on larger projects knows that the bulk of the effort is carried by a smaller group of dedicated people over long periods of time, not hundreds of over-the-fence-throwing typo-fixes. And I'm totally siding with projects who don't want to adopt the github ways of organizing their work where it means making long-haul contributor's lives more difficult.
> More people use Git and contribute to FOSS in a single day in 2022 than every developer who knew all these tools combined back in 2008 or whatever.
[Ref. Needed]
> > Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive.
> Sorry, but I consider this to be a similarly made up claim that's just sour grapes.
If "gamified" may not be the right term, you certainly can't be oblivious to how often people equate their github activity to their resume, and how it's used as a token of value by job hunters and recruiters alike. Putting aside the "merit" of most contributions, this really contributed to people "demanding" from projects to move to github, to bring visibility on themselves (before the interests of the project itself), hence the centralization around the single largest platform. I don't know about you, but I find this state of affairs quite discomforting.
Git is a twisty maze of operations combined under poor names (e.g. git reset) with dozens of obscure options (e.g. man git-log) and broken abstractions (e.g. what is HEAD and why does Git emit a warning whenever I check out a tag?). I often feel so sad that the entire software industry has fallen to Stockholm syndrome under Git — we think these contortions are normal, when in fact they are arcane.
Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions from Mercurial in favour of always using node hashes everywhere, arguing that for their gigantic repos, sequential revisions were so big as to be useless.
Eventually the disagreements were too great, and Facebook just stopped publicly talking about Mercurial.
I figured they would emerge a few years later with their fork of it. They love doing this. HipHop VM for PHP, Apache Hive, MyRock; these are examples of Facebook forking off their development in private and then later emerging with some thing they built on top of it.
The Mercurial project is surprisingly still chugging along, and there are still those of us who actually use Mercurial. I doubt I'll switch over to Sapling, because I disagreed with the things that made Facebook fork off in the first place. But if others like Sapling and this manages to put the slightest dent into the git monoculture, I'm happy for the change and innovation. I really hope that git is not the final word in version control. I want to see more ideas be spread and that people can see that there can be a world beyond git.