A quirk I have is I don't like it when IDEs interface with my version control system. That is MY version control system. Don't touch my stuff, IDEs
But! I have another quirk, which is that I don't like git, and I use Mercurial for everything
And the quirks cancel each other out! I check my projects out in Mercurial, which is obscure, so IDEs don't support it, so their VCS integration fails and I am happy
My toolchain is no longer obscure and hipsterish enough to be free of IDE integration!!! The toolchain is gentrifying!!! I guess now I gotta switch to Pijul
@aeva@mcc it has diffs optimized for large binary files, doesn’t require downloading every revision of them, and they’ve got an intent to add file locking support, but I think it’s still probably less suited to it than centralized VCSs are.
@oblomov@mcc Give it bad credentials, so that when it tries to integrate, it fails.
(There might be options to ask for a prompt every time it wants to check out a file, but that might just be adding a wishlist that's in UE4/5 and Perforce integration.).
@mcc I prefer Mercurial too, which means my personal projects tend to be on less mainstream forges which is fine... but sometimes it's annoying, like when projects to analyze software supply chain security only support GitHub projects 😐
@dalias yes, but horrifyingly although android studio is based on gradle, in my experience you do not get exactly the same results building with command line gradle than in android studio
@inthehands Hasn't really changed much in years. Depends on when you stopped using it I guess? They replaced the janky "branch" feature with something called "bookmarks" which is much better, and then they tried to introduce something called "phases" that doesn't really add anything and I've never heard of anyone using.
@inthehands Someday I will write a tutorial. I believe for it to be really good you have to turn on three or four plugins which are shipped by default but off by default.
@mcc It’s been a decade at least. (!) I do hope I have occasion to use it again. My memory is loosely “same features as git, but with less stupid names.”
@inthehands to me hg is basically just "svn with push and pull" and i love svn
pull and update are separate verbs and this is so important to me. mercurial seems to give you verbs for actually interacting with & reshaping the tree whereas all git wants to do is interact with your current source checkout and lots of tree operations seem to require making the branch you want to operate on your current source checkout. It feels unnecessary. (also: git often requires you to make a named branch)
@mcc My experience with Mercurial was that its command mnemonics actually made sense, and it was nice to use...but nobody else knew how to use it, so my attempts to use it in collaborative projects just added a bunch of extra friction.
@byobattleship so here is the thing there are no longer any convenient places to host mercurial repos. so using mercurial pretty much means pushing and pulling to github and everyone you interact with will just be using git
@chandlerc@byobattleship it's actually pretty straightforward. Use bookmarks for your branches, never "hg branch". Internalize "anonymous branches are local-only, bookmarked branches can be pushed and pulled". Use gitignore not hgignore. That's pretty much it.
The one big critical issue is hg git, last I checked, didn't support git lfs, which is essential for some applications. But they were working on it last I checked.
There is one tiny nightmare: If you use hg strip, you can sometimes get a bizarre message the next time you use hg-git about a commit not being found. You then have to open a file named .hg/git-mapfile and manually delete the line with the "not found" hash. This… should not work this way, IMO. I should probably try to write a patch actually
Take note of this from hg help hggit, u can use git hashes for both input & output but u have to mark them as such
@mcc absolutely, this is super interesting to inform whether I should really try out this workflow. TBH, I'm reassured and more strongly considering it. =D
@mcc@inthehands git is a database, not a VCS. You could build both hg and svn on top of git. And people often try, but very badly. Awful fucking thing.
@TomF@mcc@inthehands unpopular opinion I guess, but I think one of git's main problems is that it is a distributed VCS, which then leads to all sorts of wacky "git workflows" which try to turn it back into a centralized VCS (because centralized makes a lot more sense for most teams)
@floooh@TomF@mcc@inthehands Git makes some hard things simple (distributed VCS etc.), at the expense of making some simple things hard.
It is one of life's great amusements that arguably its main popularity driver has been a website, git_hub_, that focuses on providing a centralised version of it.
@TomF having written code for a git client, I unfortunately must conclude that if it is a database it is not a very good one. If you try to use its format to store something other than what it expects you to store it fights back in various ways. I think this is the case people use "leaky abstraction" to describe.
@mcc@inthehands OK I'm a bit confused by this criticism, since for does have “split semantics” although with different names (fetch and merge) and nearly every single operation I can think of acts on any reference regardless of whether it's a (named) branch or not (except for one that specifically manipulate branch names), but I also don't understand what you mean by “tree operations”, so I'm probably missing the core of the criticism.
@tthbaltazar because the interface for git is a medieval torture device and git's command line interface is so deeply intertwined with its file format that all attempts to make an alternate or wrapper interface just wind up being the command line interface with fewer handles on critical components
git is constantly printing the most bizarre error messages in the least helpful way
If you try to hg checkout SOMEID in an hg-git repository, where SOMEID is the SHA1 hash of a Git commit in that repository, it won't work. You have to use a special revset to select a Git commit by SHA1 hash with hg-git.
Similarly, if you use hg identify to get the current commit hash and give it to a Git user, it won't work. You have to find and give them the Git commit hash, not the Mercurial commit hash.
Add comment