I've seen teams evaluate multiple revision systems before starting projects and each one has decided on Mercurial based on its technical merits.
I'll take it on trust that git is a perfect solution for linux kernel development, but the number of teams who work the same way as them is a rounding error from zero. I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same.
I don't want to have to spend time understanding how my editor handles lines in memory in order to use it, why should I have to spend time understanding how my revision control system treats revisions?
Tech is hard enough without having to sink time in to unnecessarily complicated tools that can bite you in the bum really hard.
I think this explains a lot of the initial popularity of git and github. Wanting to be like the cool kids, and git knowledge being seen as somehow "elite" back then.
But given that initial popularity, it seems likely to me that network effects mostly explain its growth in usage from there. Convergence on a single revision control tool/site/representation/api/etc is probably inevitable, in the same way that there is basically a single social network (ie Facebook).
The big advantage of git is github and co, not git itself. By switching and using mercurial you lose all of the advantages of github too.
The irony is I use git for all my projects, too, due to the network effect. It's vastly easier to go with the flow rather than swim against the tide. But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :(
cough Fossil cough
I think you can pay as low as 2 dollars a month to use SourceHut.
Yeah, but saying that here a few years ago got you lynched.
It's worth going through old HN comment sections that have flamewars of SVN v git (or cvs vs hg or whatever) from 2006-2012 or so. The dvcs systems won because they changed a bad paradigm to one that's much much better - literally the way you think about version control these days is a radical departure from the previous way it was done. Merges are much much nicer in git then they ever were in those old systems - I've never spent more than an hour dealing with the results of git issues, but I've lost literal weeks to a single svn mishap.
Why did git win over other dvcs systems?
2 main reasons I see:
1. Linux uses it - literally, that means its the "cool one"
2. Linux uses it - and that means the people developing it work similar to the kernel, they are willing to try a lot of different ways to acheive the task resulting in both some amazing cool stuff and a lot of cruft left hanging out for various compatability and "accidentally super important structurally" reasons.
Being merely better isn't enough; see mercurial.
The use case actually has to be important to people in real life, too, not just be something that sounds cool or people might say is important but they don't actually exert any effort towards implementing; see fossil.
The problem is that it's not clear what that will be. It wasn't hard to tell branch merging was a huge weak spot of SVN even if you were close enough to it to not see the forest for the trees. What is git's weak spot? People might jump up to say "interface!" but the reality is, no, it's not; again see mercurial. Talk is cheap and complaints are cheaper but the reality is the community is not switching en masse because of that. Large binary files is certainly a weak spot and I understand there are some commercial solutions for that that edge out git, but that's not going to edge out git in general because the pain isn't enough for most projects, and while git-lfs isn't necessarily the slickest solution ever it's good enough for programming projects. Submodules are awful but it's not clear to me that there is enough pain there to make people switch even if you made that slick as can be. (Plus, if something did start eating git's lunch because of that, there are improvements git can make that would blunt the impact. Git's fundamental model means submodules are always going to be weird but it doesn't have to be as bad as it is. I think backwards compatibility prevents git from fixing the problems but if something was really a threat it could overcome that and they'd be improved.)
I expect to still be using git for many many years yet.
I strongly feel if someone could match the merging ability of Git with the ease of simple, well worded commands, it could win. And it doesn't even have to be a Git replacement, but a better frontend. Kind of how yay is to pacman. Or how most use something like Handbrake instead of ffmpeg.
In a lot of ways, it reminds me of Python and Perl. Perl was definitely more powerful as a language, but Python felt like natural writing in pseudocode. Enthusiasts rightly point to the power of inbuilt regex, but like Git, few actually could harness it well enough to make that unreadability worth it.
But we have that, and not only didn't it win, it shows no sign of winning. Mercurial isn't even growing in apparent mindshare.
"Easier" and "technically sound" is by observation, not by a long line of strained theorizing, not enough. Theories must take this fact into account or be useless in explaining the real world.
If you're going to collaborate in a decentralized way you ultimately need an accepted mainline source of truth.
From the point of view of someone stuck on subversion, all of that is freaking magic. This is what I mean about "radical departure". By analogy, there's people who think of horses as slower cars and say things like "why can't we just start using horses again" without ever considering the horse issues that are no longer relevant like: having to feed them every day, having to not ride them too long without resting the horse, what do to with all the poop, and so on because cars don't even have analogous impediments.
"Everyone" uses GitHub as a single source of truth, but I believe that git itself was not designed with this in mind. GitHub users use git as centralised version control with "local commits, rebases or whatever".
> Any time you create a branch locally, without needing to contact the central server you are using distributed vcs. Same when you do local commits, or rebases or whatever.
I think that it is possible to add local branches and commits to centralised version control. Will it make it decentralised? I don't think so.
> From the point of view of someone stuck on subversion, all of that is freaking magic. This is what I mean about "radical departure". By analogy, there's people who think of horses as slower cars and say things like "why can't we just start using horses again" without ever considering the horse issues that are no longer relevant like: having to feed them every day, having to not ride them too long without resting the horse, what do to with all the poop, and so on because cars don't even have analogous impediments.
It's not a topic of "horses vs cars" you know. Not even close. This analogy is a plain trolling IMO.
Well, you think wrong, because it's not. Centralized change control will contact the central server for every change.
If you can make local commits, it's decentralized source control. Prove me wrong: show in the SVN or p4 or CVS documentation where you can create local branches or commits while the central server isn't reachable over the network
But using GitHub as a single source of truth for git repositories makes git mostly centralised. Think of it as of SVN with local commits and a central repository on GitHub (with its UI). And with awkward git’s CLI.
I don’t think that SVN, p4 or CVS have support for local commits. What I want to say is that local commits could be added into centralised version control systems. Come on, SVN has a local working copy. Won’t it handle local commits?
The fact that you keep coming back to github to "prove" it's somehow centralized at the vcs level is clearly you just doing some contrarian trolling.
I assume the most trivial case when say I contribute to e.g. MS documentation, which source is now available exclusively on GitHub. Can I say that this MS docs repository is a canonical copy?
I think that the most common daily use workflows with git and GitHub are absolutely centralised regardless of the decentralised nature of git.
* I have a local git repository, its local version history and all the great features this provides. But I have to push to GitHub, you know. Can I somehow publish my changes if GitHub is down? So how is this different from centralised version control?
* GitHib provides extra features besides version control. It has a bug tracker, wiki, whatever. I'm tied to all these features, and they are not decentralised at all. I understand that this analogy is silly, but GitHub is a well done SourceForge with Git. But it's still SourceForge, and it's centralised.
When I use git with GitHub, I usually only clone, commit and push and check my project's issue tracker. All these actions except commit require access to GitHub. So I think that the workflow is absolutely centralised even if git is decentralised by design and has local version history.
I think that's what @evouga meant in his comment above when he said > But almost nobody actually uses git the way it was originally intended, eg. as decentralized version control? Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to.
The company I work for has internal forks/clones of many projects hosted on GitHub.
I routinely interact with at least four different clones of a project: the upstream one on GitHub; the local one on my machine; my personal clone on GitHub for upstream contributions; and the company-internal clone hosted on some company-internal server.
So yes, we are using git in a decentralized fashion.
Just let some junior developers to some rebases and squashes, and see what happens.
Linus Torvalds developed it after the spat with Bitkeeper, which was the main public proprietary dvcs.
In a short time it became the most popular one. Which means all these people must be wrong otherwise.
OpenBSD can use CVS cause they have a small, relatively static team.
And at that point, even the use of dvcs was in question, so you could use svn on google's forge, or sourceforge. Launchpad had bzr support too.
It wasn't clear github was going to win until it was clear that git was going to win.
Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git)
I know you have no time to know your tool. But I don't see any hurdles to allocate one evening and read https://jwiegley.github.io/git-from-the-bottom-up/. It gives a model that you can apply to other distributed VCS and may be make you a better engineer.
It helps that Mercurial has a really nice cross platform GUI: TortoiseHg. Version control is one of those things that really benefits from a GUI because you're manipulating small elements complex object - the commit graph. Using the command line is bit like using ed to edit a text file (i.e. with commands like "insert xyz between lines 12 and 13").
1. I want some changes in my repo to be persistent whenever I switch to a new branch, pull, or merge a remote.
2. They should not be shown in git status.
3. They should not be pushed.
From skimming the front page I haven't found whether something like this is supported.
I see that with stgit I can `stg pop` my "persistent changes" before pushing to the remote and then apply it again with `stg push` but that requires that I use stg commands to create patches instead of `git commit`.
I did, plus MS SourceSafe, Team Foundation Source Control and Bazaar.
I don't see the problem with SVN and Mercurial. If you have merge conflicts, no tool is going to solve that.
If you love git so much, try to do a squash merge to the main, then do some other changes in your branch, and try to merge again. Have fun solving all the merge conflicts that actually shouldn't be there.
Like I said, SVN and Mercurial are fine too. I don't see any reason why git would magically solve some merge conflict that SVN or Mercurial is not able to.
Why I should want to do it? It feels unnatural. What problem you are trying to solve by this workflow?
I'm very curious how your favorite VCS handle this case.
For this situation, at the end just do:
git rebase -i main
And delete all of the commits that you included in your squashed commit. If you want to preserve your detailed history you can create a new branch for the rebase like so:
git checkout -b mybranch-rebase && git rebase -i main
If you want Git to continue keeping track of your commits, don’t squash-merge them.
Squash merging loses valuable history in general and use of it is a sign that commits on source branches are being made carelessly.
(That said, if I had to do this, I’d rebase off of the squash before merging again and have no problems.)
From experience, this is just straight up wrong. I came from an SVN enviornment which was all GUI tools.
Git's learning curve was steep but extremely short. Once you know what is happening, even those crazy states you can find yourself in really are not that hard.
I think we're saying the same thing. Once you know how Git works, it's easy. But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push?
Once you can picture what's happening, absolutely. I can think of some other cases that require a lookup later like one I had to lookup after: 'rebase v merge' for example, after a 5 min documentation read, and with a picture in your head of how your state is it makes sense.
You're right if you're looking for 'how git works under the hood' that's a bit different. I might have misunderstood your sentiment.
Everywhere it'd bee seen as a flaw from ux standpoint, but git gets a "pass"
Imagine having to read excel's or windows code in order to use it consciously, lol.
>You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared).
Impl details of e.g dbs, std libs, runtimes, compilers, etc are for advanced/expert cases, not for slighly above normal
It's like how for a word processor the domain is text, et. al., or for e.g. Inkscape the domain is SVG.
Git has two levels, called "plumbing" and "porcelain" (I think.)
The "plumbing" (blobs, trees, commits, refs, and index) is elegant and easy to understand and use.
The "porcelain" is where everybody gets bogged down. I'll omit my own opinion (low) and just say that most of the problems people have with git seem to be related to trying to do complicated things with the crummy UX porcelain.
And that seems to be because they learned the porcelain but not the plumbing.
So what you're hearing is people advising people to learn the plumbing (as a side effect the porcelain becomes less unbearable.) In fact, if you know the plumbing you can write your own porcelain, and it's not hard and the code is brief because git is actually elegant and easy to understand and use.
You have to have some mental model of what the program is doing. With SVN it's basically "the server has the latest version, you can download or update that". With git it's "You have commits (snapshots of the whole state of your directory) which are addressable by the hash of that commit and refer back to previous commits. Also, here's a bunch of tools to manipulate and share that". The gp list of terms you should know is pretty close to just covering that.
For me I like git because it doesn't guess what I want to do, it give me tools to do what I want and then does what I tell it.
The other thing is, like you say, git itself is a terrible way to learn these concepts. A command line interface is great for expressing operations, but the state, before and after, is basically invisible. I think this might be especially hard for more visual people. When I was learning data structures drawing them out and "seeing" the structure was vitally important and I know it's not just me because computer science books are filled with pictures.
I really want there to be a GUI I can recommend people to use for git, but I'm not aware of a good one. I use magit which helps a lot, but I can't recommend that to most people. All the other GUIs I've seen are just about doing command line stuff with a mouse.
At least, that's how it went for me. It seemed horribly complicated, but once I started using it, it was no issue.
For very large projects (eg Linux-scale or Windows-scale) I can totally see why it is the best versioning solution. But most software isn't like that: it's relatively small teams maintaining a legacy codebase and making fairly incremental enhancements. I struggle with what git brings to that vs the cognitive overhead of using it.
I've recently migrated a moderately large codebase from TFS to GitHub. A large part of what drove that was co-workers who were reluctant to use TFS - I suspect that they found it old-fashioned, and that kind of bothers me, even though git is clearly the future and TFS clearly isn't. I like diversity of tools, and tools that don't force me to think too hard about things that should be easy. The knowledge that git could turn into a foot-gun just when I most need to get things done, doesn't help.
<edit> After some consideration, I think what I'd like is a tool that gives me a simple SVN-style UX over a real git repo, with the option to drop down into actual git of necessary, and so that colleagues can use only git if they prefer. Github desktop partly achieves this, as does Visual Studio's git integration, but it's not quite what I want.</edit>
(Not a git hater. I've had a github account for over a decade and choose to use it a lot for personal projects. But mostly just simple, sequential check-ins over time.)
I won’t defend the git porcelain because it is incredibly baroque, but because it’s backed by a robust a simple data model underneath I see that as more of a rote memorization challenge than a fundamental flaw. This is far preferable to svn which conflates repos, directories, branches and tags, resulting in the possibility of nonsensical operations and unresolvable merge situations.
There are also very few use cases that require its complex distributive model.
I'm not saying it can't be better - clearly it can.
Just pointing out that one person spending a little time unfucking a branch is massively superior to everyone not being able to work because that same person fucked up everyone's branches.
i dont know why mercurial doesn't get more love.
Github really is git's best PR.
From a developer stand point the experience was better but all the tooling and integrations are git based so we switched.
Actually, wait. hg up doesn't require network access. Maybe you're thinking of hg pull -u or svn up
Don't get me wrong I appreciate mercurial devs did a tremendous work to hide DVCS under SVN-like ("simple" hah) interface. But every non-standard thing requires manual reading.
So it's like `git checkout` and doesn't cover all breakage cases.
My personal reasons for liking mercurial is some pretty amazing tooling (hg absorb, hg fa --deleted, revsets/filesets) combined with a friendly commandline with fairly sensible defaults.
It's a tool aimed at technical people, which at the time it was launched offered features and technical possibilities which was unmatched by most other popular source-control systems at the time.
I remember going from Microsoft's Team Foundation Version Control to Git, and everything just felt miles more flexible and capable.
Especially branching was enormously limited with Microsoft's offer, while Git literally allowed me to merge anything I wanted, across any base, and usually end up where I wanted to be.
In short: Git solved real world problems in a way which more than compensated for its somewhat clunky UX.
Did you see what came before? Git isn't popular because of its UI, it's popular despite its UI. It's considered worth it because of its distributed model and speed.
Having said that, I've used magit pretty much from the start and can't understand people who don't switch to a better UI eventually. I don't think a command line UI works well for it at all.
>Even a simple merge/rebase leaves one confused.
I've never had this problem. Git always works exactly as its designed for me.
You obviously have not used the alternatives that were available before Git. After CVS and Subversion, Git was just a breeze of fresh air. But UX still has a lot of room for improvement.
Definitely the best way to learn.
> Even a simple merge/rebase leaves one confused. Which should I use?
Merge merges two branches. You fork a branch off master, work on stuff until it's done, then merge it back into master. After that the branch can go away.
Rebase is for rewriting history. To get rid of the 20 embarrassing commits where you tweaked stuff at random hoping to get it to work, or to redo a bunch of changes in a more coherent and easier to review way. It can be used to transplant work from one branch to another. It also can be used to keep up with the changes in the branch you forked off from.
> What is incoming? Why does incoming change as you progress?
Not quite sure what you mean, could you provide more details?
> I didn't change anything (on purpose) but Git won't let me change branches.
Probably because changing branches would lose your current work. It can happen either mid-rebase, or because you modified a file that would be overwritten by a branch change.
> How do I just unfuck what I did and go back to a branch?
You can abort a rebase with `git rebase --abort`. This loses progress.
> Git might have awesome tech underneath, I really don't know or care. But someone needs to really spend time in a typical dev's shoes to make it nicer to use.
I agree the UI leaves a lot to be desired. But the main thing is that you need to understand what it is that you want to accomplish first, especially in the merge/rebase question.
Similarly, for most things you don't ever have to touch Git on the command line. There are tons of great interfaces overlaying Git - e.g. Sublime Merge, which can visualize what you're doing, and makes Git significantly "nicer to use". You can still descend into the command line, but for whatever you've described above, you don't have to, and you don't have read manpages for common use cases.
Your problem with Git is not an insurmountable issue - it's about finding the right tool to use Git with, and which is the way moving forward anyway. Consider ffmpeg. It's extremely powerful, and about as arcane as git, and you'd needs just as many manpages or Google searches to understand it. Yet most people just use software that overlays all the magical conversions that ffmpeg enables - and no one has to see or blame ffmpeg per se. The scenario should be similar with Git, I hazard.
Though even knowing, Mercurial is still a better experience, but not by enough.
Makes life a lot easier
Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and today people still just nuke a directory because they can't figure out the arcane arts. I am one of those people, at times. Because it's faster to do so than read heaps of manpages for a situation I may never hit again.
Git might have awesome tech underneath, I really don't know or care. But someone needs to really spend time in a typical dev's shoes to make it nicer to use.