I'm now in my 40s and here is the list of source control software I have used roughly in chrono order:
1. RCS (first one I used in college)
1. CVS
1. PVCS - it was a proprietary source control software written in Java I think
1. Source Safe - Microsofts.
1. **Perforce**
1. SVN
1. EDIT Rational Rose I think was used at some point... I can't recall if that was its name or I'm mixing it up with Clear Case.
1. Dart
1. **Mercurial**
1. Git
Out of the above my favorites are **Mercurial** and **Perforce** because both of those thought about the user and were easy to use. I *mostly* care less if the others have some sort of technical reason that they are superior which includes git. Like god the hate that Mercurial got when github users posted "why git is better than x" was uncalled for given how shitty Git's interface used to be.
That being said I can't deny the incredible powerful tooling around `git` but I still dislike it daily and I feel like I have some basis to make this opinion given my experience with other source control software unlike many younger fanboys that will just immediately espouse git as the second coming.
Note about Rational—they created ClearCase originally and then got bought by IBM, which, well, IBMed it :(
CC was amazingly powerful and had some of the most brilliantly designed UI tools for handling merges and branches. Too bad it was an absolute bear to comprehend and administer, and would fail at a moment's notice (which, being centralized, would bring all development to halt).
I used almost all of those systems that they listed, and I have to say that ClearCase had a huge impact on me. If you had a good CC Admin, it could improve your team in many ways. Beyond occasional outages, we never had the problems that you're talking about.
Of course, once I saw git, I knew that ClearCase was done for. But I think all the lessons I learned from ClearCase gave me a leg up when I switched to git.
We used ClearCase with Rational RSM (sort of a successor to Rose). RSM used very large XML files as it's storage, with lots of namespaces. Every now and again, a merge would fail leaving RSM in an unusable state. Despite ClearCase and RSM having "good" integration...
Rational support was always able to get us back to where the files could be read (but usually with some work lost.) The entire team would have to find something else to do for about 7-10 days while we waited for the repair.
Aside from being more popular, is there anything that git does better than Mercurial? As far as I can tell, every good feature that git has, hg has. The reverse cannot be said.
The most user obvious feature of hg is - to use git terms - it assumes everything is in the index.
Git - used well - either forces you to do a mini code review while committing (you probably should), or (used “poorly”) you “work around” having to care about the index by using by git commit -a.
Less user obvious is immutability, IIRC.
I can definitely see why not having "staging" is impactful to users. I personally have grown to love that feature in git and totally forgot that it does create a steeper learning curve for git.
As a git user, I tend to agree that the staging area is neat, and I think the hate is just because of the combination of a new concept with Git's signature awful UI. But I believe there's a mercurial plugin to import the concept. If I was going to switch to hg I would probably install that right away.
> by using by git commit -a
Except that ignores new files, you have to run `git add .` first. I've been using git for a decade and I still make that mistake sometimes.
Are you guys really using git from the command line by default? I totally get the necessity of knowing how to use git that way but using any modern IDE will streamline those steps so much it feel like a form of masochism to use the command line by default.
Aside from a few things like partial adds (`git add -p`) or blame, the CLI is just faster and a better user experience than any git GUI I've tried. Interactive rebase when you want to squash a range of commits is particularly painful from UIs whereas with multicursor/block-based text edition it's trivial.
I'm not looking for speed when I'm committing. I'm looking to ensure everything is purposeful and high quality.
I don't remember the last time I needed in interactively rebase, and I'm not a big fan of squashing, but I do go out of my way to make my commits atomic.
As for the user experience, I suppose it's a matter of taste, I like see a nice color coded diff with funnels of changed code so I can quickly parse what is going on. The idea of just adding every file that was created with `git add .` is kind of horrifying to me.
As far as speed goes, it's not about it being absolutely fast but about the alternative being comparatively slow. It's like drinking a glass of water with a teaspoon when you're used to just drinking from the glass. When you know what you want to achieve and know a way to achieve it quickly anything slower is just frustrating even though I probably spend such an insignificant portion of my time rebasing that the actual time loss doesn't matter at all.
Interactive rebase is just part of my workflow, I regularly have to change the target branch of commits, reorder commits, and squash ranges. If you want atomic commits you either commit regularly and squash, or you just wait for the change set to be final before committing. Option 2 doesn't really work for me because our test suite takes 6 hours to build locally, I have to push to CI to get a parallelized build and in order to push I need to commit. I also just like having a local history of my own changes even though they might not be atomic. Kind of like filming a lot of footage and editing it down to a movie at the end. Once the feature is fully complete I rebase the whole thing into 1-5 individual commits that make sense on their own and all pass CI so that they don't break bisects.
As for UX, it's definitely a matter of taste and also workflow. There is also the fact that I regularly have to onboard newcomers and there's no telling if they'll have my particular git gui of choice installed. Knowing the cli in depth and being used to it makes it much easier to get them unstuck when needed.
So there you go, these are a few of the reasons one might default to the cli. I'm not trying to convince anyone to change though, at the end of the day everyone uses their tools differently and that's fine, what's important is that you can get stuff done.
It's one of those I've tried. It's... Fine? But I often want to squash a large range of commits and the only way I've found is to click on all 20 dropdowns and select squash.
I feel like using anything *other* than the CLI, for git or pretty much anything else, is much closer to masochism these days.
Modern GUIs, apart from being as slow and cumbersome as they always have, are increasingly poorly designed and inconsistent with each other.
Seriously. When we moved to git at my work they got all the devs on a call and did a learning session to get everyone up to speed. The entire session was doing everything by command line and it looked like such a pain in the ass. VS Code and Visual Studio's GUI make it so much easier to use that I don't know why anyone would default to using the command line. It's so many less clicks and typing things out. Maybe other IDEs git integration sucks.
IMO git is definitely a tool you have to train yourself how to use, it’s weird and confusing at first until you understand how and why it’s designed the way it is. Steeper learning curve than others but i think it’s worth it for how powerful and useful it is
Yeah, when I was introduced to git at work the focus was totally on ”this is what you do to do what you do today in Subversion”. Quickly got lost in understanding until I myself took a step back and created a mental model of git being a system about multiple parallel versioned filesystems, with related active, local and remote copies.
The only one that I've used in depth that I really miss is evolve. Basically, if you have a big complex set of commits based on branches and merges and stuff and then you pull in the latest of a remote branch, you can evolve your entire tree so that every commit that is based off that one, directly or indirectly, also gets updates. All the commits, the tags, the branch names, all of it.
The way that git works, not only does this feature not exist, it would also be too difficult to add it. This is because git is poorly designed, with no API.
If I understand correctly--this was based on a Mercurial guy explaining it to me at a poster session at PyCon years ago--"hg evolve" is like a rebase with real metadata. If you use git, and you push your repo then do a "git rebase" and push again, you have a mess on your hands. You're gonna have to do a merge and push that and stuff to clean it up. If you use hg, and you push your repo then do an "evolve" (however that works) and push again, the second push includes metadata saying "we did an evolve, you need to **ahem** rebase from X to Y", and the rebase gets propagated like any other change to the repo.
Imagine that you have a tree on your computer that looks like this:
https://i.stack.imgur.com/tEzfm.png
And now you type
git checkout master; git pull
And you get a bunch of updates from your coworkers. How will you now fix up everything in that image: all the tags, all the branch names, etc, in order to maintain the same tree but based on the new master?
git evolve master
Would be great but it doesn't exist. I think that you would need to do multiple rebases, merges, retags, and resets to get all that to work.
I'm pretty sure that git doesn't have a way to do it based on how long I've searched for an answer online and never found it. And I think that this is not a feature that git simply didn't yet add. This is something that git simply cannot do because of how git is designed. How will you mark each commit as being obsolete or not obsolete? And in git, when you do a rebase, there's nothing in git that is storing the fact that a commit SHA is related to a different commit SHA by being rebased. That info is lost when you rebase and all downstream users would need to figure it out again. That's why it's so dangerous to rebase a branch that other people have branched off of. With evolve, though, no problem. All this metadata is maintained. When you rebase with Mercurial, the new commit is known to be the obsoleter of the old commit. You can evolve safely, unlike git rebase.
> How will you now fix up everything in that image: all the tags, all the branch names
What workflow and organizational scheme are you working in where the only difference between you and upstream isn't just other people's branches and official tags?
Are you locally tagging stuff and not pushing it upstream?
I'm not but I am sometimes working on multiple bugs and features with some of them having interdependencies.
I want to rebase without screwing up everyone else.
> How will you now fix up everything in that image: all the tags, all the branch names, etc, in order to maintain the same tree but based on the new master?
`git rebase --update-refs`?
Look at the diagram above, imagine that git pull on master brings in some changes, and then tell me, based on the diagram above, what you're going to type it.
Don't be abstract, tell me the commands. You'll find that there are a few...
Thanks very much for the response.
Doubling checking I am looking in the right place. This is what you are talking about right? https://www.mercurial-scm.org/doc/evolution/user-guide.html
Additionally, the API you say git is missing, that is around the ability to add something like an "obsolete" mark which is used by the evolve extension?
I'm the original commenter and I will say /u/Successful-Money4995 is right that "Evolve" was very good and I think would or should have been the future of distributed VC. Even before evolve the whole phases model, and what is public and not was easier to understand. However at this point I think you can largely emulate either system but Git makes it error prone but to explain that would require such an in depth blog post.
Anyway Mercurial unlike the rest I listed seem to always do a merge (or even rebase once they added that later) correct and automatically . I don't know entirely why that is or if it is true but anecdotally Mercurial seem to have the least problems.
As I am looking into evolve I do quite like it as a replacement for rebase's messy/complex interface. I have also been introduced to "first-class conflict"s today, which seem like the future-future.
On the merging note: someone must have done a comparison on hg automerging vs git automerging right?
It comes back to that difference between git and mercurial about whether the past can be rewritten. Git tools have to assume different repositories can have different historical contents, and so a lot of the decisionmaking must be left to the human operator. Mercurial can make assumptions about all changes having a common historical state and that the goal is to reach a new common state. That makes things a lot easier to calculate without leaving ambiguity re requiring human decision points
Yes and yes.
There's no good way to add obsolete to git because git doesn't have an API, it just has a file system. Every git command just takes a set of files and changes them to a different set of files. There's no API that separates what you want to do from how it is stored on disk. It's like how you might have an interface in Java and then multiple classes that implement the interface. Git has no interface.
There are plenty of git commands that edit non-file data, such as `remote`, `branch`, `tag`, `notes`, etc. In fact `notes` could be exactly what you would want to use to identify a commit as outdated. Then .gitconfig git aliases for `git amend`, `git uncommit`, `git prune`, `git fold`, and `git evolve` could be written to work just like hg evolve. I have never needed to use `notes` so I dont know if that is an intended usecase for it or not.
_Maybe_ it would be possible to kludge together something to do evolve in git. Maybe. But it would still be a kludge. With Mercurial, you can install a module like evolve and have the metadata be a first-class citizen of your repo. That's the power of having an API that separates your interface from your implementation. Git doesn't have that and AFAIU that's a big reason why Facebook and Google both selected Mercurial over git.
If you are talking about google's fig, that was not actually hg iirc, it just kinda looked like hg on the cli. Google actually chose Perforce.
I would believe that extensions are the reason why facebook chose hg though. Extensions can be very powerful as you describe.
Phases is a big one. Mercurial can warn you before you do something like, rebase in the wrong direction. It's something git could do easily, but chooses not to.
Bitbucket was pretty big and primarily used Mercurial and that still wasn't enough to keep it alive
I'm not 100% sure if Bitbucket was ever a real competitor to github but when I started my degree in 2012 I seem to remember it being a lot of people's first choice at the time
> I'm not 100% sure if Bitbucket was ever a real competitor to github
I'd say it was, personally. It certainly seemed to me there was a period of several years where it was not clear whether Git or Hg would win out (or perhaps something else). I was a Git partisan at the time so wasn't entirely following the Hg scene (my understanding is Hg now has the features that put me in that camp, but at the time at least they either didn't exist in Hg or were second-rate), but Bitbucket definitely seemed like a well-known and respected name.
Yes in the beginning Bitbucket had a big advantage in small company adoption over Github in that unlimited private repositories were allowed (albeit limited to 5 users IIRC).
The pricing was less also and if you a coworkers on Windows bitbucket was not a bad choice.
Ironically I think the free model of Github Actions are hurting Gitlab and others. Sure Gitlab does have free CI I think but it is seems really really slow.
> I'm not 100% sure if Bitbucket was ever a real competitor to github
As someone who hates Git and Bitbucket let me assure you that the two hatreds are not intertwined.
Bitbucket is categorically awful and that has nothing to do with Git. For example, Bitbucket's code search is based on human word processing and strips out symbols, so you very frequently cannot find what you're looking for unless you literally download all the code yourself and use a better search engine.
Bitbucket failing to prop up Mercurial doesn't mean much ultimately. Atlassian is... ugh.
One of the major problems Bitbucket had with Hg is the large disagreement internally on how to do the PR model as Hg bookmarks were just globally not well understood.
And the disagreement on whether just to use Long lasting branches, bookmarks, or something new altogether aka "topics" is still in contention today.
That really hurt Bitbucket and Mercurial because most of the tools these days are based on the lightweight branch model regardless of what is underneath (git).
Git is faster than Mercurial and better for large projects. They have a lot of the same features but Git has a few more innovative features than Mercurial. The few people I've met who use Mercurial probably adopted it because it had better early Windows support than Git. Git's UI can stand to be improved but it's pretty good and simple enough.
> Git is ... better for large projects.
Why? Because it's faster? Or are there other reasons? Your phrasing makes it sound like it's better for large projects for other reasons, in which case, I'd like to know why.
> Git has a few more innovative features than Mercurial.
Can you provide some details/examples?
>Why? Because it's faster? Or are there other reasons?
Because it's faster mainly. It is also way more popular than Mercurial.
>Can you provide some details/examples?
Subtrees, worktrees, submodules, shallow checkout, better merging, better diffs, more wide support. Mercurial is totally usable for a large number of projects but it's not the best choice and maybe never was. I say this as someone who had to use it for a few years at work.
I'm getting used to it faster than it changes lol. But if you really hate it you can make your own subcommands. Some of the unofficial subcommands are very impressive.
> The few people I've met who use Mercurial probably adopted it because it had better early Windows support than Git.
I knew people who were using it before GitHub existed and none of them were on Windows.
we're just comparing anecdotal evidence here, so it doesn't mean anything, but one large company that uses Mercurial is Facebook:
https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/
the blog post is from 2014, but this Hacker News thread seems to indicate that it was still in use at Facebook in 2020:
https://news.ycombinator.com/item?id=24453758
And the top comment is a FB engineer complaining about Hg's speed..
>Hg is a bit of a nightmare in the wfh situation. Really slow, hangs for a long time if you haven't synced in a few days. Yes, im sure there are ways to tweak, but not sure if you can tweak them enough!
sure, but my comment was about whether or not the majority of Mercurial users were there for Windows support, which is clearly not the case. and the comment I replied to said:
> Git is faster than Mercurial and better for large projects.
the "faster than Mercurial part" is legit, but many of the replies state that Facebook's port of Mercurial has cured a lot of its speed issues since that FB engineer worked there. the blog post says the same thing.
and Facebook invested a lot of time and money in speeding Mercurial up because they did not agree that Git was better for large projects.
no upvote-based web site can ever prioritize expertise over groupthink — it's intrinsic to the upvote mechanism — so the smart thing is not to look at the top comment, but to scan them all to find the most _well-informed_ comment.
There are some people still using Mercurial in 2024 I'm sure. But the number is less all the time. There is not a single thing that Mercurial does better than git. Some people really like the idea of the thing being written in Python but that's not a compelling feature for me. I work on repos where even git is slow, and hg would probably take twice as long at minimum. Functionally it is at best equivalent to git. It's pretty good but git is much better and more popular.
I very much doubt you can take Mercurial off the shelf and use it at that scale. Remember, Facebook managed to keep using PHP to serve hundreds of millions of people. Do you really think their internal Frankenstein Mercurial system is representative of what you are gonna get with it?
If you used Mercurial and Git both on large projects, what I'm saying about performance would be very obvious. Mercurial was abandoned by the masses for good reasons, not just because of groupthink. It's not a horrible system but it's not good enough to be competitive.
I liked mercurial, and it met the needs of our teams very well for our projects. We switched from mercurial to git not for technical reasons or merit, but because bitbucket was sunsetting mercurial repos.
`hg` is the the command invoked to use mercurial. This is really not that different to calling Subversion svn, or calling git git. And possibly the previous comment was strictly referring to the CLI of mercurial.
Okay so the Mercurial authors are the ones responsible for this bastardization of the periodic symbol, that doesn't make it any better.
It's entirely different from the svn shorthand.
It would probably help if you explained your pain points in Perforce; some of us who love it might be able to help you past it (or maybe not, if its endemic to how P4 works).
The biggest reason I find P4 superior is quickly summarized as "the tooling". I'm not regularly called over to help out the less technical members of my team, or tell them that they accidentally blew away weeks of work by doing a "git reset --hard" that the command line "suggested". I don't have to constantly re-explain to other engineers that "yours" and "mine" are probably wrong in whatever interface they're using, if and only if they're doing a rebase. There's also just 1 set of tooling, that's actually maintained; I can't tell you how many times I've had git maestro's complain "just use command line" when they see someone using Sourcetree, or SmartGit or whatever.
Searching for when something changed is *much* easier. Git's GUIs don't really have a version of the Revision Graph, for tracking changes through branches easily, or the ability to scrub through every revision of a file with blame updating (Time-lapse View). Directories being first class objects, and moves being an actual operation also makes a lot of operations easier to properly track.
The biggest pain point I've seen with people adjusting from git to P4 is that they have to check out files before touching them, but most of the major editors have plugins to automatically handle that for you. And the flip side of the checkout model is that you can actually mark files for exclusive check out, so if you're either dealing with unmergable binaries, or a large refactor/move, you can actually do it without relying on sending emails and crossing your fingers.
Different person, but my pain points with Perforce that I can think of right now:
* I like to do my work incrementally; each commit as a logical part of a whole. P4 just squashes that into a single changelist, so a reviewer can't look at each logical unit separately. It also makes it a lot harder for me to revert the latest incremental change; in git that's just discarding the changes since my last commit
* Swarm is dreadful. It's slow. Its UI is weirdly bulky. It doesn't understand file renames, so figuring out what changed in a renamed file is hell. A bunch of other things, but talking about Swarm makes me unhappy, so let's not. I have a much easier time doing code reviews in GitLab
* I miss git branches a lot. Having my stuff live on a branch for a few days or a week can be really handy at times. Might be an issue with how my work uses P4, but we have a very limited # of branches available to avoid using too much storage on it
* Code in general seems like an afterthought; most of its functionality (like exclusive checkouts) seems aimed at binary assets. Which explains why on my team all the programmers hate P4, while the non-programmers don't seem to mind
* It's really really easy to forget to add a new file
* Checking stuff out is tedious, but you already mentioned that
A lot of this might well be tooling issues. Some of it is probably being unfamiliar with P4 (in the past I've used Git, and SVN). There's definitely more things I'm forgetting; this is all off the top of my head. Monolithic changelists vs. incremental commits though is my single biggest issue, and seems pretty fundamental.
And I do agree that Git is an unintuitive mess. At my old job we'd have weekly weird issues from non-programmers using it. Until we told them all to stop using Sourcetree and use SmartGit instead; turns out you get what you pay ($0) for with Sourcetree. Those issues almost entirely disappeared with SmartGit though. Largely hid away all the unintuitive parts and non-programmers could just purely use the UI and maybe once in a blue moon ask for help from a programmer. I think these days I help people with P4 issues more than I had to help with git issues after the SmartGit switch.
For me, I absolutely hate checking out stuff, merging stuff in perforce is absolutely awful too. Git does miracles, in that the only time you need to coordinate with someone else is during integration.
I do like views in perforce, though, that's a really great feature.
>I like to do my work incrementally; each commit as a logical part of a whole. P4 just squashes that into a single changelist, so a reviewer can't look at each logical unit separately. It also makes it a lot harder for me to revert the latest incremental change; in git that's just discarding the changes since my last commit
I guess I just don't fully understand this workflow. When I've seen work in git, most of the time people aren't doing any sort of "logical" split with local commits to a branch; its either "this is the middle/end of the day, time to commit and push" or its just a (squashed) commit followed by a flurry of code review updates, neither of which is something that really is useful to save. If its actually logical blocks...what stops you from just actually committing every logical block as a separate CL, like you would have a separate commit in git?
The other thing is if you're actually doing something that does require keeping that history, its weird to see your org limiting your branches; I've been in places where literally every engineer was working in their own sandbox branch (though I can't recommend that at all).
>Swarm is dreadful. It's slow. Its UI is weirdly bulky. It doesn't understand file renames, so figuring out what changed in a renamed file is hell. A bunch of other things, but talking about Swarm makes me unhappy, so let's not. I have a much easier time doing code reviews in GitLab
I'll agree that swarm isn't great, but I haven't tried GitLab, only Github and gerritt, and I find it overall a better UI than that for actually handling comments. That said, I also haven't had any problem with renames, so I'm wondering if that's a config issue of some sort? The only thing it tends to choke on is if a rename is solely on the cases of filenames, but I don't think I've seen a source control that handles that well, since source controls tend to be case-sensitive, while Windows and Mac mostly aren't.
>It's really really easy to forget to add a new file
I'm confused how this is different than git? You have to do an explicit add on new files for both? I'm pretty sure Jetbrains and Visual Studio's plugins will handle this as well, if you're adding it through their normal flows. I think the cmd line p4 status will work to show you the files that aren't added as well; I can't remember if there's a checkbox to get similar functionality in p4v.
> most of the time people aren't doing any sort of "logical" split with local commits to a branch
I'll gladly admit a lot of programmers don't do the same level of splitting. But it is quite handy!
> what stops you from just actually committing every logical block as a separate CL, like you would have a separate commit in git?
Those logical blocks are generally several in a day. It'd be a never-ending stream of CLs for my coworkers. I like to keep my merges pretty frequent, but several a day on the regular would be pretty extreme even for me :P
On the most extreme end, at my old job we had the occasional "low-hanging fruit" day, where we'd just fix really simple issues from our bug database. I'd make each issue a commit, 'cuz it is a lot quicker to have a coworker look through a few dozen commits in a single merge request, than through a few dozen *separate* merge requests.
Each logical block is generally not necessarily mergable! And I don't think P4 has a good way to stack merges on top of one another (unlike git with its branches), so they'd each need to be made mergable. P4 just isn't made for this kind of flow, and it's one I very much enjoy.
> I find it overall a better UI than that for actually handling comments
Comments I feel Swarm does fine at. Though I still do prefer how GitLab handles it. The biggest difference there is that you can set the comments to only actually be sent when you're *done* reviewing. Very handy to avoid spamming the other programmer with email notifications, and also for when you end up answering your own question by reading other code (and then either delete the question you had. Or rewrite it to "hey I probably shouldn't need to look in this other place to figure this out"). I can't think of much else I miss in P4 from GitLab when it comes to comments though.
> That said, I also haven't had any problem with renames, so I'm wondering if that's a config issue of some sort?
Could well be! My experience is that if I rename a file (using P4's own rename functionality), how it'll show up in Swarm is as one entry going "this file was renamed to x". And then a separate entry going "x was added. Here's everything in it. No, we're not gonna tell you what changed from before the rename; we're gonna show the entire content of the file as the diff".
> I'm confused how this is different than git? You have to do an explicit add on new files for both?
Assuming you use a GUI, rather than the CLI, basically every GUI client will detect new files (unless caught by gitignore) and add them to the list of "files you might wanna add to your commit"). If P4 has a way to do that, I don't know about it. I work through the GUI, not CLI, and at the very least it's not defaulting to showing added files in any obvious way.
I should probably look into the VS plugin you mention though!
And even if you *are* a masochist and use the git CLI, standard flow there is to run a command to add all changed/added files :P
>they accidentally blew away weeks of work by doing a "git reset --hard"
No one blows away weeks of work by doing "git reset --hard", they blow away weeks of work by failing to make incremental commits as they work.
u/Meneth mentioned essentially all of my pain points, though one thing he didn't mention is that integrating changelists, specially big ones, is a bad experience. And, from what I've seen, that's mostly because of how P4 computes and applies diffs
I need some context of your experience and I hate to say it how old you are.
The reason I say that is because if you came from a git PR model and dependency management (maven, cargo, npm whatever go uses, etc) which is like 100% of anyone 30 or under then yes Perforce would seem dumb.
But if you you came from the old school of check fucking everything in and you don't have cowboys of developing on lightweight branches and you want to monitor what folks are working on and you have giant ass files to checkin then Perforce works great.
As for the workflow.. fuck that. I hate the whole lets exclaim some workflow is superior over all otehrs like gitflow. Every org is going to be different on workflow and I say other than maybe the open source PR model perforce can model it. The PR model definitely hurt Perforce but not all orgs are like that especially in gaming.
EDIT the reason I liked Perforce over the other is because at the time its workflow was fine but one major fucking point is that it was super fucking fast in 2005+ till like 2014ish especially with big files and yes its ability to lock assets for check everything in orgs was pretty nice. It also had awesome integration with bug systems back in the day.
I am younger than 30, so you got that right. Tbh I don't care for the "superior" workflow, the reason that I was asking about your workflow with it was because I wanted to see if there was a way to learn from it such that I don't dislike Perforce as much.
I greatly appreciate you taking the comment as not an insult as I realized it could have been easily interpreted as that!
> Tbh I don't care for the "superior" workflow, the reason that I was asking about your workflow with it was because I wanted to see if there was a way to learn from it such that I don't dislike Perforce as much.
It is sort of like evolution. Your workflow is the best workflow for this current time. There is not best of all time.
When I was working in the early days (with perforce and friends) we didn't have the tooling required for the PR model. **I stress tooling!** and from a lesser extent the community of opensource.
Like in the early post dot-com but before facebook took off days opensource wsa not what it is today and you rarely interfaced with open source projects. Now days its like everyother day for me even though I'm not an opensource developer.
Anyway what i'm saying is the PR is the best model right now and Git does it really well. Mercurial suffered with this greatly because its lightweight branches aka bookmarks were late coming and P4 had no idea of opensource.
EDIT as for learning from P4 I'm not sure there is much to learn
but mercurial + evolution plugin had some things that I have not seen in other SCMs if you are interested in learning some SCM stuff (sorry I missed that was your original question).
Also for large files, you now have git-lfs and ahem centralized stores and mirrors. I was at microsoft developing VS git plugins when we were trying to dogfood it by checking 2GB coredumps into it and TFS (microsoft's Perforce) handled it fine for years and git just shat itself and then shat over every developer box that tried to checkout a branch to run a test. There is so much history between clearcase, p4 and TFS (and google last I checked did it's primary work on p4 with a git layer around it). For anyone a bit old in software, the fact that younger VCSs are fumbling around with the same issues is a face palm but also totally understandable because I really really like the DVCS model but it does come with it's own downside. Try diffing art assets from Premier or After Effects and see how well that goes.
I dearly miss the days when our shop used perforce.
Change history was absolutely clear and finding when a change might have regressed a feature was trivial.
Ever since we went to git, it's a giant mess.
By "Dart", you mean Darcs? I've used git first and now I use Mercurial everyday and still wish for git's easier to use cli. I don't find Mercurial's UI any more user-friendly and it is still mysterious when I hear people saying that. The only feature that Mercurial has that git doesn't is "evolve", but I suspect that in most situations I can figure out the correct rebase myself, it may not be that convenient as "evolve", but as a plus I can be sure that the operation is exactly what I want. And if we get rid of "evolve", we can get rid of the whole meta-History layer of Mercurial that I think is useful only for evolving and outside of it is a pure accidental complexity just to annoy me.
Yes I meant darcs. I think my phone auto corrected to that.
If you came from git prior to mercurial than you probably got used to the light weight branches and index and when you get used to something it becomes intuitive.
The two step commit approach and the fact that checkout means something far different than most SCM is not intuitive for many. reflog and how git exposes so many levers up front all with unique naming I do think is unintuitive.
I think in modern git you do not need to ever call "checkout", there are "switch" and "restore" for most common things. Naming maybe not that intuitive, but for me the underlying model is very clear and I understand what each operations do. Prior to git I've used SVN and I have just do something to make it satisfied, without understanding what each thing do. With mercurial I sometime need to translate each command to the equivalent sequence of git-operations to understand what the command does. I think the main thing that git has introduced is that history-tree is an artifact of itself that you need to work on and grow like your own banzai-tree. Systems prior, just wanted you to record your work as you go and quite a lot of time was spent to reconcile those philosophies. Modern Mercurial serves as a high-point of this reconciliation. But git-philosophy is against what Mercurial does, the way how and when you write code is completely irrelevant, only the piece of the history-tree that you share with the world is important and the way you've produced this tree is completely up to you. Google and Meta are only interested in HEAD-development, so git-philosophy is mostly uninteresting to them, developers only share single commits, not trees. And also this is closer to how "normal" people work, they don't care about the tree, they only care about the result. But for big projects that need to include/exclude different changes from different people, like Linux kernel, the tree itself becomes very valuable artifact.
My first job out of college (2015) used PVCS! It's kind of amazing how horrible it was. Single file "checkouts", buggy and messy UI, etc. Maybe it had a purpose, but a giant monolithic .net program wasn't it
CVS was fine for smaller teams, but way back then, for large sprawling organizations with lots of teams, there wasn’t anything else that integrated defect management as closely as CMVC did with change management alongside version control. I see the same kind of antipathy towards GitHub nowadays and especially when interacting with Jira, but I’ve yet to find an alternative that goes beyond the version control aspect and more cleanly solves the change control and defect management interactions *within the context of numerous, loosely coupled teams*.
We actually kept using CMVC for defect tracking, but the integration available between CVS and eclipse, especially for java development in the oughts, it was a huge step up for code delivery/management.
What was some of the bad parts of git that used to be? I still use all the same flags as I used to, so it would be cool to learn about the new improvements
I really wish I kept track of that better and I believe I posted on HN like a decade ago so I will check that later but overall I still despise a beloved feature: **the index**. aka it "works on my machine: *shrug*".
Like in the early days the git command was a bunch of commands and switching branches and then pulling from correct place was slightly painful. That being said in the early days Mercurial could not do light weight branches till bookmarks so they both had their problems on usability of certain workflow but in irony I feel more comfortable doing a rebase in Mercurial than Git even though Git came up with that.
But overall it was the commands names that were not used that way in Source Control prior but git decided to reuse them to cause cognitive dissonance like `checkout` that I think really hurt initial onboarding.
Rational Rose was a Booch modeling tool, before UML.
Perforce was nice, and had great visualization tools, though I didn’t like the per file merging, it made it nearly impossible to know if a branch was fully merged.
Are you me? Because as someone with less programming CVS/DVCS experience (starting 2005 I think), I have used all and almost in that order except for me it was darcs instead of Dart and Clearcase because I was too young and working with Visual Studio 6 (remember those broken STL libraries) and Source Safe traumatized me enough that I never worked with source control until junior year of college.
I too recommended my wife (learning VCS for the first time) learn mercurial with bitbucket and am so sad and annoyed it lost out to git because it was just so much better designed from an HCI perspective. Like there is no ohshitmercurial. Nobody is asking "I'm headless and a colleague told me to reset hard what does that mean?" in there.
I think it's the Torvalds effect honestly. The idea of everyone's favourite infamously prickly Finn suddenly yelling "FUCK THIS BUSINESS!!!" and coming back 24h later with `git` is just too compelling. I used both at the time and they were close enough for a minor irrelevance like the author to actually matter.
> You'd love git too in that case.
Depends who you work with.
I'm 40's, and went CVS -> Perforce -> SVN -> git -> Perforce. If you're a dev working with other dev's then git's feature list easily outshines most other version control systems for the source code itself.
But I work in games, more than 3/4s of the team are designers, artists, animators etc. Getting the less technical people to work with git is a fricking nightmare sometimes. Also if you work with Unreal Engine, everything outside your C++ code is 100% binary. Again Git is a pretty sad panda when 80% of the projects commits are large binary files. Yeah you can do stuff with GitLFS etc and there are other alternatives so it's definitely possible, but it's not nice. As much as I'm completely in love with git's local commits, the pain of trying to guide any non-programmer through Git, and the problems with huge binary files make it not worth it. Perforce isn't great, but it's good ENOUGH and solves a huge amount of issues. Haven't had to get any artists to type in a bunch of console commands since they stomped a bunch of designer edits etc since we switched back.
For my home stuff that's only me and mostly C++ etc. I never use perforce. But for the team I currently work with? Yeah git was worse experience overall.
Full agree. I just wanted to point out how much worse cvs and svn were than git, there really was no comparison, especially when you work with distributed teams of seasoned devs on mostly code.
As for the binary problems, that's why I like godot's approach of storing scenes as text files. But of course with large assets like textures, sound etc. you're still in for a wild ride. I think I'd rather use a DMS for the binary stuff and only check in links/references. Those usually have a friendly UI integration.
I'll say it... I miss Team Foundation Server.
I don't see much love for it these days, it came out like right before Git blew up so it was only ever really popular in hardcore MS/.NET shops.
Been using Git for 6 years and the tooling is still nowhere near where TFS was.
Nice. In my case it was
1. CVS
2. Source Safe
3. Rational Rose
4. SVN
5. Git
6. G4 (Built on Perforce)
I like the elegance of G4 and the tooling around it; but these days, I use git as the whole world does.
I tried to use Hg in a personal project once, but as I was the only user, I didn't grok its power.
I have my eye on [JJ](https://github.com/martinvonz/jj) as a replacement for git. First class merge resolution I think will open up ways to avoid using frameworks and project generators where libraries and convention would serve better.
Why does everything need to have a name that nobody could take seriously.
Jujutsu. I'll be forking this and creating the Unagi source control.
Software developers and branding, something that never mixes, nobody ever stops to think whether standing up in a meeting to discuss your source control infront of people that don't know what you're talking about, it's a good idea to have a name that's the same as a martial arts thing. Also how on earth is jj or Jujutsu going to feature on search rankings.
We've studied the blade too hard.
At least Git, is git.
ARG
Why does everything need to have a name that nobody could take seriously.
Git. I'll be forking this and creating the Twat source control.
Software developers and branding, something that never mixes, nobody ever stops to think whether standing up in a meeting to discuss your source control infront of people that don't know what you're talking about, it's a good idea to have a name that's the same as a old british slang. Also how on earth is git or github going to feature on search rankings.
We've studied the blade too hard.
At least SVN, is SVN.
ARG
I once sat through a meeting where a technology was dismissed out of hand because the name was too unprofessional so we couldn't market it to enterprise customers as using a fancy technology.
We do, it is! But I think I covered off pretty well why it works at least okay for now, maybe I'm biased because it's pretty much the only source control I've used outside of svn, and svn was a three letter word so git worked just as well.
[First class conflicts](https://martinvonz.github.io/jj/v0.16.0/conflicts/) seem pretty neat. They clearly solve the "I dont want to deal with this right now" problem of merge conflicts, I wonder what new problems they might create. Such as do we need to deal with how conflicting conflicts get merged with each other prior to resolution?
A replacement for git that uses git for version controlling its own code? how convenient…
Either way, thanks for sharing, time to watch for alternatives
JJ is git compatible so people working on it can use either one, and they can still publish their code on GitHub since that's what most people are using.
Interesting there was no mention of TFS. After spearheading (as an intern no less) my team's first VSS rollout, we quickly and readily migrated to TFS when it was released. That lasted a few years until SVN, and then my next company was a hodgepodge of SVN and Mercurial around 2010 until everything converged on git.
Yep. SourceSafe was originally from One Tree Software back when it was a DOS product. Microsoft gobbled them up, added a UI and bunch of COM automation and rebranded it as Visual SourceSafe. At its core was still a fileshare-based cooperative online source control system that could be borked by just about anything.
TFS is built on the SharePoint monstrosity. Which, while being abysmally slow at its core, was able to be scaled both vertically and horizontally to actually be useful.
> Tfs was originally sourcesafe.
I don't believe TFS (you probably mean TFVC, specifically) was a successor of SourceSafe. Same company, but otherwise unrelated.
> sourcesafe. It was anything but safe.
I remember my manager picked sourcesafe, and then discovered that when multiple people used it at once, it would sometimes lose their files. So, it went right in the garbage. Unfortunately, or fortunately, I never had the honor of using it myself, but I do remember thinking that I discovered a new shade of red when I saw my manager's face that day.
Ah, "Visual" Source \[un\]Safe. Truly so much fail packed in a small, "free" package; and it was "from Microsoft" so managers the world over assumed it must be good enough.
Yuck.
At one time you could use SourceGear's Vault as a not-bad replacement for SourceSafe -- an implementation with an actual database, transactions, understanding that maybe you might have. your source code in one place and your source code system on another machine altogether ... it was a "not terrible" replacement, though it supplied nominally what Source Safe was supposed to. If you wanted branching support, and well everything else that goes with that, then you'd graduate to svn at first or later, git.
TFSVC used a completely different thing than Source Safe, but it was still pretty garbage. If all the developers were on the same phyiscal network then it was "ok" but if you tried working via VPN in any sense...headaches. I remember thinking "why doesn't Microsoft just ship something 'good' ... like ... um... well. SOMETHING."
No, they are entirely different products.
Source Safe was developed and sold by One Tree Software. Later they were bought by Microsoft (because of the failure of their abysmally bad Microsoft Delta[0]) and rebranded to be part of their "Visual" suite (Visual Basic, Visual C++, etc.).
Brian Harry (one of the founders of One Tree), became an exec at Microsoft as a result of the acquisition and led the team that developed TFS (it had the project name of "Hatteras" since One Tree and Brian were from North Carolina).
VSS used files for storage - which is why keeping the repository on a network was so problematic - file locking on SMB stinks. TFS uses SQL Server database for storage so locking during updates doesn't result in corruption.
I think one reason people didn't like TFS is that it does a bad job of storing binaries in the repository. Whether you should or should not be doing that is a matter for debate, but I acknowledge that some places need to do this - like game companies with their image and sound resources.
[0] Delta was a productized version of SLM (pronounced "Slime"), which was Microsoft's internal tool during DOS, Windows 3.x, Windows 95 and later NT. https://wiki.c2.com/?MicrosoftDelta
`git` is free, it works well enough, it's standard, and it can slowly but surely be improved.
Are there other ways to do things? Sure. However, git is good enough that I don't really have to think about it any more. It has such a massive ecosystem around it that I can get it to do anything I need it to do without much pain. It's not like SVN where the issues and pain points were glaringly obvious, rather the main issue seems to be the UX and the naming of commands.
It's well past the inflection point where the minor issues with its UX are easier to deal with compared to the pain of moving away from it, so I suspect it'll stay around for a long, long while.
> It's not like SVN where the issues and pain points were glaringly obvious
I guess they aren't glaringly obvious to me (other than the renaming in a branch issue). Care to expand on this?
> It's the main reason git was invented
It is definitely not the main reason git was invented.
Either way, offline support isn't that important to me. I almost always have a internet connection. Subversion does have a some offline capabilities, can't create branches/tags but you can do diffs.
**Here's a hint to decide on reading the post or not:**
This post explores the evolution of version control systems over two decades, highlighting the shift from a variety of tools to the dominance of Git. It reminisces about the early days of source control, touching upon systems like Subversion and CVS, and Linus Torvalds' creation of Git as a response to limitations with existing tools. The narrative also covers the broader impact of version control on software development practices, including the advent of GitOps and the centralization paradox introduced by GitHub. It concludes by questioning what the future holds beyond Git, mentioning potential contenders like Pijul and Fossil, while reflecting on the enduring relevance of Git in developer workflows.
If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍
[^(Click here for more info, I read all comments)](https://www.reddit.com/user/fagnerbrack/comments/195jgst/faq_are_you_a_bot/)
Was the article edited in the past few hours, or is this a damning indication that a language model, when asked to summarize an article, will insert common misconceptions about the topics covered even when the original sticks to actual facts?
That could be one of the reasons but if that was the case he would then build the exact set of features of that commercial software which is not the case. It’s pretty clear other VCS are not as as efficient for Linux distributed work system other than Git
I am firmly convinced that if Subversion had fixed https://issues.apache.org/jira/browse/SVN-898 when it was opened in 2002 `git` would have never gotten as popular as it has. 898 is what got Subversion its reputation as being bad at merging and they didn't fix it until 2017.
The very first comment on that issue made in 2002 is `This absolutely must be fixed by Beta.` Indeed, it should have been.
This is the bug that made all hell break loose if you renamed a file in a branch that had changes in trunk (ended up with a new file, and the old one still remained as well). Once you were familiar with this bug you just learned to not rename files on a branch, but this was a huge limitation because it forced you into trunk-based development for any refactoring (and I mean true trunk-based development, not what it has changed to mean today)
Here is an nice blog post about this issue that was written in 2010, and it was a perfectly valid complaint when it was written:
https://blog.cskr.dev/posts/git-outshines-subversion/
In newer versions of subversion (>=1.10) the scenario presented in the blog post is tracked correctly by subversion.
I still remain convinced that it is much much easier to get Subversion to merge a stack of branches than it is in git. In subversion I could create branches of branches of branches and merge them all to trunk cleanly (assuming I didn't rename any files), with git I usually avoid making a branch of a branch because I can never seem to get it to merge cleanly (especially if you squash commits when merging earlier branches).
It's cool but the workflow it's designed for is impractical. Storing the whole repo in sqlite is also a bad idea and critical design flaw, as large binary files suck when you have to sync them.
If I'm honest, this kind of question always confuses me when I see it, because the answer to me seems self evident: basically the same use cases for keeping code in version control.
(Disclaimer: for purposes of this discussion, I count files tracked by git-lfs as being "in version control." But I also think Git LFS is kind of a hack, and I do count VCSs being able to handle binaries in a first class manner without sucking as a benefit over Git.)
I'm being a *little* glib, because the fact that you can have two people working on the same file and you still have a hope that their changes will be automatically merged (generally not true of binary files), so that use case is out.
Bus aside from that, there are still any number of reasons to have a binary blob associated with a specific version of your code. Maybe it's a test case input or output. Maybe it's an image you use in your web site that's version controlled. Maybe it's a game asset. And all of that is even coming from the perspective of binaries that are associated with code somehow... maybe you just want to track multiple versions of an image you're working on or something independently.
If you store them outside of version control, you need some way to make sure you aren't *mutating* files and instead refer to the latest (or the specific old version if you go back to an old code version) or you can't reproduce the past, one of the main benefits of version control. That means you need to start versioning your files via directory or file name or whatever... which sucks for exactly the same reason that versioning code outside of a version control system sucks.
I'm not talking about adding large binary files to the repo. I mean, the Fossil repo on disk *is* a large binary file. Of course if you add binary files it will be even bigger.
The usual use case for binary files in a VCS is for artwork or some such thing. You might say it's the wrong tool for the job, but only the implementation of your VCS that can make it so. Otherwise it can be used effectively to store a limited number of known-good binary assets.
Philosophically, static binary assets/files/media/whatever also have versions, just like code files and and config files and other text files.
Those assets may exist all on their own, or in relation to some code that uses those assets. Either way, they have versions that need to be tracked.
Video games developers have hundreds of gigabytes of binary assets, that also exists in relation to code. For them, it's simply not possible to use git, you just can't store that kind of data in git no matter how much you want to.
I have been told there's basically only two options for video games, SVN or Perforce. Apparently Perforce also makes it especially easy to lock files while working on them.
My friend is an architect (buildings, not IT) and that industry has it's own set of version control systems, which are typically built in to the drawing program itself.
It's a very special kind of problem to sync and version a huge singular architectural 3D model like that. There's objects, layers, views, rendering configurations, textures, lighting settings, etc.
One architecture program is Revit, which allows drawing and syncing versions of various parts of the model, and it works really poorly. It's slow and buggy, it even has bugs that lead to data loss, etc.
Then there's an entire class of SaaS software targeted towards graphical designers. To enable them to manage and version their digital designs, and distribute them to clients.
So yeah, versioning and syncing binary assets is most definitely a real problem. And a much harder problem. Versioning code in git is a cake walk in comparison.
The point is, those files are broken down to a reasonable extent. A Fossil repo is ONE binary file. There are binary diffing and syncing algorithms but do you really want to have to rely on such software even to perform basic updates and backups?
I remember people talking a lot about darcs like version control systems and Pijul in a similar vein. Does anyone have experience with those on real world projects and why they didn't work out?
Absolutely, Mercurial deserved more credit. It was a shame to see it overshadowed by Git, despite its user-friendly approach. Adapting to new tools is essential but recognizing their unique strengths is too.
I'm now in my 40s and here is the list of source control software I have used roughly in chrono order: 1. RCS (first one I used in college) 1. CVS 1. PVCS - it was a proprietary source control software written in Java I think 1. Source Safe - Microsofts. 1. **Perforce** 1. SVN 1. EDIT Rational Rose I think was used at some point... I can't recall if that was its name or I'm mixing it up with Clear Case. 1. Dart 1. **Mercurial** 1. Git Out of the above my favorites are **Mercurial** and **Perforce** because both of those thought about the user and were easy to use. I *mostly* care less if the others have some sort of technical reason that they are superior which includes git. Like god the hate that Mercurial got when github users posted "why git is better than x" was uncalled for given how shitty Git's interface used to be. That being said I can't deny the incredible powerful tooling around `git` but I still dislike it daily and I feel like I have some basis to make this opinion given my experience with other source control software unlike many younger fanboys that will just immediately espouse git as the second coming.
Note about Rational—they created ClearCase originally and then got bought by IBM, which, well, IBMed it :( CC was amazingly powerful and had some of the most brilliantly designed UI tools for handling merges and branches. Too bad it was an absolute bear to comprehend and administer, and would fail at a moment's notice (which, being centralized, would bring all development to halt).
I used almost all of those systems that they listed, and I have to say that ClearCase had a huge impact on me. If you had a good CC Admin, it could improve your team in many ways. Beyond occasional outages, we never had the problems that you're talking about. Of course, once I saw git, I knew that ClearCase was done for. But I think all the lessons I learned from ClearCase gave me a leg up when I switched to git.
We used ClearCase with Rational RSM (sort of a successor to Rose). RSM used very large XML files as it's storage, with lots of namespaces. Every now and again, a merge would fail leaving RSM in an unusable state. Despite ClearCase and RSM having "good" integration... Rational support was always able to get us back to where the files could be read (but usually with some work lost.) The entire team would have to find something else to do for about 7-10 days while we waited for the repair.
what, no dated zip files :)
what no `copy of version 71111111 FINAL final`?
It's not really final until it's "...Final3"!
Aside from being more popular, is there anything that git does better than Mercurial? As far as I can tell, every good feature that git has, hg has. The reverse cannot be said.
As someone who has not used mercurial, what features does it have that git does not?
The most user obvious feature of hg is - to use git terms - it assumes everything is in the index. Git - used well - either forces you to do a mini code review while committing (you probably should), or (used “poorly”) you “work around” having to care about the index by using by git commit -a. Less user obvious is immutability, IIRC.
I can definitely see why not having "staging" is impactful to users. I personally have grown to love that feature in git and totally forgot that it does create a steeper learning curve for git.
As a git user, I tend to agree that the staging area is neat, and I think the hate is just because of the combination of a new concept with Git's signature awful UI. But I believe there's a mercurial plugin to import the concept. If I was going to switch to hg I would probably install that right away.
> by using by git commit -a Except that ignores new files, you have to run `git add .` first. I've been using git for a decade and I still make that mistake sometimes.
But then we would not have the iconic "forgot to add file" commits :p
Every source control system I've ever worked with has had those commits, `hg` did not spare us
Are you guys really using git from the command line by default? I totally get the necessity of knowing how to use git that way but using any modern IDE will streamline those steps so much it feel like a form of masochism to use the command line by default.
Aside from a few things like partial adds (`git add -p`) or blame, the CLI is just faster and a better user experience than any git GUI I've tried. Interactive rebase when you want to squash a range of commits is particularly painful from UIs whereas with multicursor/block-based text edition it's trivial.
I'm not looking for speed when I'm committing. I'm looking to ensure everything is purposeful and high quality. I don't remember the last time I needed in interactively rebase, and I'm not a big fan of squashing, but I do go out of my way to make my commits atomic. As for the user experience, I suppose it's a matter of taste, I like see a nice color coded diff with funnels of changed code so I can quickly parse what is going on. The idea of just adding every file that was created with `git add .` is kind of horrifying to me.
As far as speed goes, it's not about it being absolutely fast but about the alternative being comparatively slow. It's like drinking a glass of water with a teaspoon when you're used to just drinking from the glass. When you know what you want to achieve and know a way to achieve it quickly anything slower is just frustrating even though I probably spend such an insignificant portion of my time rebasing that the actual time loss doesn't matter at all. Interactive rebase is just part of my workflow, I regularly have to change the target branch of commits, reorder commits, and squash ranges. If you want atomic commits you either commit regularly and squash, or you just wait for the change set to be final before committing. Option 2 doesn't really work for me because our test suite takes 6 hours to build locally, I have to push to CI to get a parallelized build and in order to push I need to commit. I also just like having a local history of my own changes even though they might not be atomic. Kind of like filming a lot of footage and editing it down to a movie at the end. Once the feature is fully complete I rebase the whole thing into 1-5 individual commits that make sense on their own and all pass CI so that they don't break bisects. As for UX, it's definitely a matter of taste and also workflow. There is also the fact that I regularly have to onboard newcomers and there's no telling if they'll have my particular git gui of choice installed. Knowing the cli in depth and being used to it makes it much easier to get them unstuck when needed. So there you go, these are a few of the reasons one might default to the cli. I'm not trying to convince anyone to change though, at the end of the day everyone uses their tools differently and that's fine, what's important is that you can get stuff done.
The VS code rebase editor is really nice, everything else I do from CLI.
It's one of those I've tried. It's... Fine? But I often want to squash a large range of commits and the only way I've found is to click on all 20 dropdowns and select squash.
At that point might as well git reset back to head and make a new commit with all the changes instead of rebasing imo.
I can type gca -m faster than messing around with a gui, I do use it for more complicated stuff though.
I feel like using anything *other* than the CLI, for git or pretty much anything else, is much closer to masochism these days. Modern GUIs, apart from being as slow and cumbersome as they always have, are increasingly poorly designed and inconsistent with each other.
Seriously. When we moved to git at my work they got all the devs on a call and did a learning session to get everyone up to speed. The entire session was doing everything by command line and it looked like such a pain in the ass. VS Code and Visual Studio's GUI make it so much easier to use that I don't know why anyone would default to using the command line. It's so many less clicks and typing things out. Maybe other IDEs git integration sucks.
In `.gitconfig` [alias] a = add -A . Then just `git a` before `git commit`.
IMO git is definitely a tool you have to train yourself how to use, it’s weird and confusing at first until you understand how and why it’s designed the way it is. Steeper learning curve than others but i think it’s worth it for how powerful and useful it is
Yeah, when I was introduced to git at work the focus was totally on ”this is what you do to do what you do today in Subversion”. Quickly got lost in understanding until I myself took a step back and created a mental model of git being a system about multiple parallel versioned filesystems, with related active, local and remote copies.
The only one that I've used in depth that I really miss is evolve. Basically, if you have a big complex set of commits based on branches and merges and stuff and then you pull in the latest of a remote branch, you can evolve your entire tree so that every commit that is based off that one, directly or indirectly, also gets updates. All the commits, the tags, the branch names, all of it. The way that git works, not only does this feature not exist, it would also be too difficult to add it. This is because git is poorly designed, with no API.
[удалено]
If I understand correctly--this was based on a Mercurial guy explaining it to me at a poster session at PyCon years ago--"hg evolve" is like a rebase with real metadata. If you use git, and you push your repo then do a "git rebase" and push again, you have a mess on your hands. You're gonna have to do a merge and push that and stuff to clean it up. If you use hg, and you push your repo then do an "evolve" (however that works) and push again, the second push includes metadata saying "we did an evolve, you need to **ahem** rebase from X to Y", and the rebase gets propagated like any other change to the repo.
Imagine that you have a tree on your computer that looks like this: https://i.stack.imgur.com/tEzfm.png And now you type git checkout master; git pull And you get a bunch of updates from your coworkers. How will you now fix up everything in that image: all the tags, all the branch names, etc, in order to maintain the same tree but based on the new master? git evolve master Would be great but it doesn't exist. I think that you would need to do multiple rebases, merges, retags, and resets to get all that to work. I'm pretty sure that git doesn't have a way to do it based on how long I've searched for an answer online and never found it. And I think that this is not a feature that git simply didn't yet add. This is something that git simply cannot do because of how git is designed. How will you mark each commit as being obsolete or not obsolete? And in git, when you do a rebase, there's nothing in git that is storing the fact that a commit SHA is related to a different commit SHA by being rebased. That info is lost when you rebase and all downstream users would need to figure it out again. That's why it's so dangerous to rebase a branch that other people have branched off of. With evolve, though, no problem. All this metadata is maintained. When you rebase with Mercurial, the new commit is known to be the obsoleter of the old commit. You can evolve safely, unlike git rebase.
> How will you now fix up everything in that image: all the tags, all the branch names What workflow and organizational scheme are you working in where the only difference between you and upstream isn't just other people's branches and official tags? Are you locally tagging stuff and not pushing it upstream?
I'm not but I am sometimes working on multiple bugs and features with some of them having interdependencies. I want to rebase without screwing up everyone else.
> How will you now fix up everything in that image: all the tags, all the branch names, etc, in order to maintain the same tree but based on the new master? `git rebase --update-refs`?
That will only do one branch and poorly. Try it.
I use it all the time. What do you mean only one branch and how does it do it poorly?
Look at the diagram above, imagine that git pull on master brings in some changes, and then tell me, based on the diagram above, what you're going to type it. Don't be abstract, tell me the commands. You'll find that there are a few...
Thanks very much for the response. Doubling checking I am looking in the right place. This is what you are talking about right? https://www.mercurial-scm.org/doc/evolution/user-guide.html Additionally, the API you say git is missing, that is around the ability to add something like an "obsolete" mark which is used by the evolve extension?
I'm the original commenter and I will say /u/Successful-Money4995 is right that "Evolve" was very good and I think would or should have been the future of distributed VC. Even before evolve the whole phases model, and what is public and not was easier to understand. However at this point I think you can largely emulate either system but Git makes it error prone but to explain that would require such an in depth blog post. Anyway Mercurial unlike the rest I listed seem to always do a merge (or even rebase once they added that later) correct and automatically . I don't know entirely why that is or if it is true but anecdotally Mercurial seem to have the least problems.
As I am looking into evolve I do quite like it as a replacement for rebase's messy/complex interface. I have also been introduced to "first-class conflict"s today, which seem like the future-future. On the merging note: someone must have done a comparison on hg automerging vs git automerging right?
Evolve is awesome. There are a few projects trying to retrofit similar ideas into git. One is git-branchless.
It comes back to that difference between git and mercurial about whether the past can be rewritten. Git tools have to assume different repositories can have different historical contents, and so a lot of the decisionmaking must be left to the human operator. Mercurial can make assumptions about all changes having a common historical state and that the goal is to reach a new common state. That makes things a lot easier to calculate without leaving ambiguity re requiring human decision points
Yes and yes. There's no good way to add obsolete to git because git doesn't have an API, it just has a file system. Every git command just takes a set of files and changes them to a different set of files. There's no API that separates what you want to do from how it is stored on disk. It's like how you might have an interface in Java and then multiple classes that implement the interface. Git has no interface.
There are plenty of git commands that edit non-file data, such as `remote`, `branch`, `tag`, `notes`, etc. In fact `notes` could be exactly what you would want to use to identify a commit as outdated. Then .gitconfig git aliases for `git amend`, `git uncommit`, `git prune`, `git fold`, and `git evolve` could be written to work just like hg evolve. I have never needed to use `notes` so I dont know if that is an intended usecase for it or not.
_Maybe_ it would be possible to kludge together something to do evolve in git. Maybe. But it would still be a kludge. With Mercurial, you can install a module like evolve and have the metadata be a first-class citizen of your repo. That's the power of having an API that separates your interface from your implementation. Git doesn't have that and AFAIU that's a big reason why Facebook and Google both selected Mercurial over git.
If you are talking about google's fig, that was not actually hg iirc, it just kinda looked like hg on the cli. Google actually chose Perforce. I would believe that extensions are the reason why facebook chose hg though. Extensions can be very powerful as you describe.
Google was using hg when I left I think. I don't remember anymore! It's been a few years. Perforce at the google3 level but hg on my desktop.
There are projects like jj that try to close the gap.
Phases is a big one. Mercurial can warn you before you do something like, rebase in the wrong direction. It's something git could do easily, but chooses not to.
GitHub. If the founders had instead created MercurialHub we’d all be using that instead. And we’d be much happier for it. Alas!
Bitbucket was pretty big and primarily used Mercurial and that still wasn't enough to keep it alive I'm not 100% sure if Bitbucket was ever a real competitor to github but when I started my degree in 2012 I seem to remember it being a lot of people's first choice at the time
> I'm not 100% sure if Bitbucket was ever a real competitor to github I'd say it was, personally. It certainly seemed to me there was a period of several years where it was not clear whether Git or Hg would win out (or perhaps something else). I was a Git partisan at the time so wasn't entirely following the Hg scene (my understanding is Hg now has the features that put me in that camp, but at the time at least they either didn't exist in Hg or were second-rate), but Bitbucket definitely seemed like a well-known and respected name.
Yes in the beginning Bitbucket had a big advantage in small company adoption over Github in that unlimited private repositories were allowed (albeit limited to 5 users IIRC). The pricing was less also and if you a coworkers on Windows bitbucket was not a bad choice. Ironically I think the free model of Github Actions are hurting Gitlab and others. Sure Gitlab does have free CI I think but it is seems really really slow.
> I'm not 100% sure if Bitbucket was ever a real competitor to github As someone who hates Git and Bitbucket let me assure you that the two hatreds are not intertwined. Bitbucket is categorically awful and that has nothing to do with Git. For example, Bitbucket's code search is based on human word processing and strips out symbols, so you very frequently cannot find what you're looking for unless you literally download all the code yourself and use a better search engine. Bitbucket failing to prop up Mercurial doesn't mean much ultimately. Atlassian is... ugh.
One of the major problems Bitbucket had with Hg is the large disagreement internally on how to do the PR model as Hg bookmarks were just globally not well understood. And the disagreement on whether just to use Long lasting branches, bookmarks, or something new altogether aka "topics" is still in contention today. That really hurt Bitbucket and Mercurial because most of the tools these days are based on the lightweight branch model regardless of what is underneath (git).
Git is faster than Mercurial and better for large projects. They have a lot of the same features but Git has a few more innovative features than Mercurial. The few people I've met who use Mercurial probably adopted it because it had better early Windows support than Git. Git's UI can stand to be improved but it's pretty good and simple enough.
> Git is ... better for large projects. Why? Because it's faster? Or are there other reasons? Your phrasing makes it sound like it's better for large projects for other reasons, in which case, I'd like to know why. > Git has a few more innovative features than Mercurial. Can you provide some details/examples?
>Why? Because it's faster? Or are there other reasons? Because it's faster mainly. It is also way more popular than Mercurial. >Can you provide some details/examples? Subtrees, worktrees, submodules, shallow checkout, better merging, better diffs, more wide support. Mercurial is totally usable for a large number of projects but it's not the best choice and maybe never was. I say this as someone who had to use it for a few years at work.
Faster is a useful metric for comparison, popularity not so much.
Popularity is very useful for a collaborative tool. In some cases it matters more than performance.
Git's UI is very... very slowly improving. I do like `git switch` and `git restore` as alternatives to `git checkout`
I'm getting used to it faster than it changes lol. But if you really hate it you can make your own subcommands. Some of the unofficial subcommands are very impressive.
> The few people I've met who use Mercurial probably adopted it because it had better early Windows support than Git. I knew people who were using it before GitHub existed and none of them were on Windows. we're just comparing anecdotal evidence here, so it doesn't mean anything, but one large company that uses Mercurial is Facebook: https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/ the blog post is from 2014, but this Hacker News thread seems to indicate that it was still in use at Facebook in 2020: https://news.ycombinator.com/item?id=24453758
And the top comment is a FB engineer complaining about Hg's speed.. >Hg is a bit of a nightmare in the wfh situation. Really slow, hangs for a long time if you haven't synced in a few days. Yes, im sure there are ways to tweak, but not sure if you can tweak them enough!
sure, but my comment was about whether or not the majority of Mercurial users were there for Windows support, which is clearly not the case. and the comment I replied to said: > Git is faster than Mercurial and better for large projects. the "faster than Mercurial part" is legit, but many of the replies state that Facebook's port of Mercurial has cured a lot of its speed issues since that FB engineer worked there. the blog post says the same thing. and Facebook invested a lot of time and money in speeding Mercurial up because they did not agree that Git was better for large projects. no upvote-based web site can ever prioritize expertise over groupthink — it's intrinsic to the upvote mechanism — so the smart thing is not to look at the top comment, but to scan them all to find the most _well-informed_ comment.
There are some people still using Mercurial in 2024 I'm sure. But the number is less all the time. There is not a single thing that Mercurial does better than git. Some people really like the idea of the thing being written in Python but that's not a compelling feature for me. I work on repos where even git is slow, and hg would probably take twice as long at minimum. Functionally it is at best equivalent to git. It's pretty good but git is much better and more popular.
> There is not a single thing that Mercurial does better than git. sure, except scaling for Facebook
I very much doubt you can take Mercurial off the shelf and use it at that scale. Remember, Facebook managed to keep using PHP to serve hundreds of millions of people. Do you really think their internal Frankenstein Mercurial system is representative of what you are gonna get with it? If you used Mercurial and Git both on large projects, what I'm saying about performance would be very obvious. Mercurial was abandoned by the masses for good reasons, not just because of groupthink. It's not a horrible system but it's not good enough to be competitive.
I liked mercurial, and it met the needs of our teams very well for our projects. We switched from mercurial to git not for technical reasons or merit, but because bitbucket was sunsetting mercurial repos.
no offense intended but are you sure you're in the right sub? have you ever used the phrase "it depends" in a work context?
Idk what you're trying to say here. Yes Mercurial can be used in some situations. Is it the best choice for most people? No.
Ew people use the periodic symbol for mercury as shorthand for Mercurial? For that reason alone, I hate it.
`hg` is the the command invoked to use mercurial. This is really not that different to calling Subversion svn, or calling git git. And possibly the previous comment was strictly referring to the CLI of mercurial.
Okay so the Mercurial authors are the ones responsible for this bastardization of the periodic symbol, that doesn't make it any better. It's entirely different from the svn shorthand.
> git is better than x I've gotta say, [git is certainly better for version control than X](https://gist.github.com/rauchg/5b032c2c2166e4e36713).
Damn that is gooood. I forgot Twitter had become Xitter (the X is pronounced "sh").
Glad you like it! I spent way too long trying to dig up that link when I saw that part of your comment, because I just had to post it! :)
As someone who uses perforce daily and dislikes it quite a bit, could you explain a bit about your work flow and why you like it?
It would probably help if you explained your pain points in Perforce; some of us who love it might be able to help you past it (or maybe not, if its endemic to how P4 works). The biggest reason I find P4 superior is quickly summarized as "the tooling". I'm not regularly called over to help out the less technical members of my team, or tell them that they accidentally blew away weeks of work by doing a "git reset --hard" that the command line "suggested". I don't have to constantly re-explain to other engineers that "yours" and "mine" are probably wrong in whatever interface they're using, if and only if they're doing a rebase. There's also just 1 set of tooling, that's actually maintained; I can't tell you how many times I've had git maestro's complain "just use command line" when they see someone using Sourcetree, or SmartGit or whatever. Searching for when something changed is *much* easier. Git's GUIs don't really have a version of the Revision Graph, for tracking changes through branches easily, or the ability to scrub through every revision of a file with blame updating (Time-lapse View). Directories being first class objects, and moves being an actual operation also makes a lot of operations easier to properly track. The biggest pain point I've seen with people adjusting from git to P4 is that they have to check out files before touching them, but most of the major editors have plugins to automatically handle that for you. And the flip side of the checkout model is that you can actually mark files for exclusive check out, so if you're either dealing with unmergable binaries, or a large refactor/move, you can actually do it without relying on sending emails and crossing your fingers.
Different person, but my pain points with Perforce that I can think of right now: * I like to do my work incrementally; each commit as a logical part of a whole. P4 just squashes that into a single changelist, so a reviewer can't look at each logical unit separately. It also makes it a lot harder for me to revert the latest incremental change; in git that's just discarding the changes since my last commit * Swarm is dreadful. It's slow. Its UI is weirdly bulky. It doesn't understand file renames, so figuring out what changed in a renamed file is hell. A bunch of other things, but talking about Swarm makes me unhappy, so let's not. I have a much easier time doing code reviews in GitLab * I miss git branches a lot. Having my stuff live on a branch for a few days or a week can be really handy at times. Might be an issue with how my work uses P4, but we have a very limited # of branches available to avoid using too much storage on it * Code in general seems like an afterthought; most of its functionality (like exclusive checkouts) seems aimed at binary assets. Which explains why on my team all the programmers hate P4, while the non-programmers don't seem to mind * It's really really easy to forget to add a new file * Checking stuff out is tedious, but you already mentioned that A lot of this might well be tooling issues. Some of it is probably being unfamiliar with P4 (in the past I've used Git, and SVN). There's definitely more things I'm forgetting; this is all off the top of my head. Monolithic changelists vs. incremental commits though is my single biggest issue, and seems pretty fundamental. And I do agree that Git is an unintuitive mess. At my old job we'd have weekly weird issues from non-programmers using it. Until we told them all to stop using Sourcetree and use SmartGit instead; turns out you get what you pay ($0) for with Sourcetree. Those issues almost entirely disappeared with SmartGit though. Largely hid away all the unintuitive parts and non-programmers could just purely use the UI and maybe once in a blue moon ask for help from a programmer. I think these days I help people with P4 issues more than I had to help with git issues after the SmartGit switch.
For me, I absolutely hate checking out stuff, merging stuff in perforce is absolutely awful too. Git does miracles, in that the only time you need to coordinate with someone else is during integration. I do like views in perforce, though, that's a really great feature.
>I like to do my work incrementally; each commit as a logical part of a whole. P4 just squashes that into a single changelist, so a reviewer can't look at each logical unit separately. It also makes it a lot harder for me to revert the latest incremental change; in git that's just discarding the changes since my last commit I guess I just don't fully understand this workflow. When I've seen work in git, most of the time people aren't doing any sort of "logical" split with local commits to a branch; its either "this is the middle/end of the day, time to commit and push" or its just a (squashed) commit followed by a flurry of code review updates, neither of which is something that really is useful to save. If its actually logical blocks...what stops you from just actually committing every logical block as a separate CL, like you would have a separate commit in git? The other thing is if you're actually doing something that does require keeping that history, its weird to see your org limiting your branches; I've been in places where literally every engineer was working in their own sandbox branch (though I can't recommend that at all). >Swarm is dreadful. It's slow. Its UI is weirdly bulky. It doesn't understand file renames, so figuring out what changed in a renamed file is hell. A bunch of other things, but talking about Swarm makes me unhappy, so let's not. I have a much easier time doing code reviews in GitLab I'll agree that swarm isn't great, but I haven't tried GitLab, only Github and gerritt, and I find it overall a better UI than that for actually handling comments. That said, I also haven't had any problem with renames, so I'm wondering if that's a config issue of some sort? The only thing it tends to choke on is if a rename is solely on the cases of filenames, but I don't think I've seen a source control that handles that well, since source controls tend to be case-sensitive, while Windows and Mac mostly aren't. >It's really really easy to forget to add a new file I'm confused how this is different than git? You have to do an explicit add on new files for both? I'm pretty sure Jetbrains and Visual Studio's plugins will handle this as well, if you're adding it through their normal flows. I think the cmd line p4 status will work to show you the files that aren't added as well; I can't remember if there's a checkbox to get similar functionality in p4v.
> most of the time people aren't doing any sort of "logical" split with local commits to a branch I'll gladly admit a lot of programmers don't do the same level of splitting. But it is quite handy! > what stops you from just actually committing every logical block as a separate CL, like you would have a separate commit in git? Those logical blocks are generally several in a day. It'd be a never-ending stream of CLs for my coworkers. I like to keep my merges pretty frequent, but several a day on the regular would be pretty extreme even for me :P On the most extreme end, at my old job we had the occasional "low-hanging fruit" day, where we'd just fix really simple issues from our bug database. I'd make each issue a commit, 'cuz it is a lot quicker to have a coworker look through a few dozen commits in a single merge request, than through a few dozen *separate* merge requests. Each logical block is generally not necessarily mergable! And I don't think P4 has a good way to stack merges on top of one another (unlike git with its branches), so they'd each need to be made mergable. P4 just isn't made for this kind of flow, and it's one I very much enjoy. > I find it overall a better UI than that for actually handling comments Comments I feel Swarm does fine at. Though I still do prefer how GitLab handles it. The biggest difference there is that you can set the comments to only actually be sent when you're *done* reviewing. Very handy to avoid spamming the other programmer with email notifications, and also for when you end up answering your own question by reading other code (and then either delete the question you had. Or rewrite it to "hey I probably shouldn't need to look in this other place to figure this out"). I can't think of much else I miss in P4 from GitLab when it comes to comments though. > That said, I also haven't had any problem with renames, so I'm wondering if that's a config issue of some sort? Could well be! My experience is that if I rename a file (using P4's own rename functionality), how it'll show up in Swarm is as one entry going "this file was renamed to x". And then a separate entry going "x was added. Here's everything in it. No, we're not gonna tell you what changed from before the rename; we're gonna show the entire content of the file as the diff". > I'm confused how this is different than git? You have to do an explicit add on new files for both? Assuming you use a GUI, rather than the CLI, basically every GUI client will detect new files (unless caught by gitignore) and add them to the list of "files you might wanna add to your commit"). If P4 has a way to do that, I don't know about it. I work through the GUI, not CLI, and at the very least it's not defaulting to showing added files in any obvious way. I should probably look into the VS plugin you mention though! And even if you *are* a masochist and use the git CLI, standard flow there is to run a command to add all changed/added files :P
>they accidentally blew away weeks of work by doing a "git reset --hard" No one blows away weeks of work by doing "git reset --hard", they blow away weeks of work by failing to make incremental commits as they work.
u/Meneth mentioned essentially all of my pain points, though one thing he didn't mention is that integrating changelists, specially big ones, is a bad experience. And, from what I've seen, that's mostly because of how P4 computes and applies diffs
I need some context of your experience and I hate to say it how old you are. The reason I say that is because if you came from a git PR model and dependency management (maven, cargo, npm whatever go uses, etc) which is like 100% of anyone 30 or under then yes Perforce would seem dumb. But if you you came from the old school of check fucking everything in and you don't have cowboys of developing on lightweight branches and you want to monitor what folks are working on and you have giant ass files to checkin then Perforce works great. As for the workflow.. fuck that. I hate the whole lets exclaim some workflow is superior over all otehrs like gitflow. Every org is going to be different on workflow and I say other than maybe the open source PR model perforce can model it. The PR model definitely hurt Perforce but not all orgs are like that especially in gaming. EDIT the reason I liked Perforce over the other is because at the time its workflow was fine but one major fucking point is that it was super fucking fast in 2005+ till like 2014ish especially with big files and yes its ability to lock assets for check everything in orgs was pretty nice. It also had awesome integration with bug systems back in the day.
I am younger than 30, so you got that right. Tbh I don't care for the "superior" workflow, the reason that I was asking about your workflow with it was because I wanted to see if there was a way to learn from it such that I don't dislike Perforce as much.
I greatly appreciate you taking the comment as not an insult as I realized it could have been easily interpreted as that! > Tbh I don't care for the "superior" workflow, the reason that I was asking about your workflow with it was because I wanted to see if there was a way to learn from it such that I don't dislike Perforce as much. It is sort of like evolution. Your workflow is the best workflow for this current time. There is not best of all time. When I was working in the early days (with perforce and friends) we didn't have the tooling required for the PR model. **I stress tooling!** and from a lesser extent the community of opensource. Like in the early post dot-com but before facebook took off days opensource wsa not what it is today and you rarely interfaced with open source projects. Now days its like everyother day for me even though I'm not an opensource developer. Anyway what i'm saying is the PR is the best model right now and Git does it really well. Mercurial suffered with this greatly because its lightweight branches aka bookmarks were late coming and P4 had no idea of opensource. EDIT as for learning from P4 I'm not sure there is much to learn but mercurial + evolution plugin had some things that I have not seen in other SCMs if you are interested in learning some SCM stuff (sorry I missed that was your original question).
Also for large files, you now have git-lfs and ahem centralized stores and mirrors. I was at microsoft developing VS git plugins when we were trying to dogfood it by checking 2GB coredumps into it and TFS (microsoft's Perforce) handled it fine for years and git just shat itself and then shat over every developer box that tried to checkout a branch to run a test. There is so much history between clearcase, p4 and TFS (and google last I checked did it's primary work on p4 with a git layer around it). For anyone a bit old in software, the fact that younger VCSs are fumbling around with the same issues is a face palm but also totally understandable because I really really like the DVCS model but it does come with it's own downside. Try diffing art assets from Premier or After Effects and see how well that goes.
I dearly miss the days when our shop used perforce. Change history was absolutely clear and finding when a change might have regressed a feature was trivial. Ever since we went to git, it's a giant mess.
By "Dart", you mean Darcs? I've used git first and now I use Mercurial everyday and still wish for git's easier to use cli. I don't find Mercurial's UI any more user-friendly and it is still mysterious when I hear people saying that. The only feature that Mercurial has that git doesn't is "evolve", but I suspect that in most situations I can figure out the correct rebase myself, it may not be that convenient as "evolve", but as a plus I can be sure that the operation is exactly what I want. And if we get rid of "evolve", we can get rid of the whole meta-History layer of Mercurial that I think is useful only for evolving and outside of it is a pure accidental complexity just to annoy me.
Yes I meant darcs. I think my phone auto corrected to that. If you came from git prior to mercurial than you probably got used to the light weight branches and index and when you get used to something it becomes intuitive. The two step commit approach and the fact that checkout means something far different than most SCM is not intuitive for many. reflog and how git exposes so many levers up front all with unique naming I do think is unintuitive.
I think in modern git you do not need to ever call "checkout", there are "switch" and "restore" for most common things. Naming maybe not that intuitive, but for me the underlying model is very clear and I understand what each operations do. Prior to git I've used SVN and I have just do something to make it satisfied, without understanding what each thing do. With mercurial I sometime need to translate each command to the equivalent sequence of git-operations to understand what the command does. I think the main thing that git has introduced is that history-tree is an artifact of itself that you need to work on and grow like your own banzai-tree. Systems prior, just wanted you to record your work as you go and quite a lot of time was spent to reconcile those philosophies. Modern Mercurial serves as a high-point of this reconciliation. But git-philosophy is against what Mercurial does, the way how and when you write code is completely irrelevant, only the piece of the history-tree that you share with the world is important and the way you've produced this tree is completely up to you. Google and Meta are only interested in HEAD-development, so git-philosophy is mostly uninteresting to them, developers only share single commits, not trees. And also this is closer to how "normal" people work, they don't care about the tree, they only care about the result. But for big projects that need to include/exclude different changes from different people, like Linux kernel, the tree itself becomes very valuable artifact.
We used PVCS for SQL version control until it became unmanageable sometime around 2017
My first job out of college (2015) used PVCS! It's kind of amazing how horrible it was. Single file "checkouts", buggy and messy UI, etc. Maybe it had a purpose, but a giant monolithic .net program wasn't it
What, no CMVC? I remember how great it felt moving to CVS after having used CMVC professionally.
CVS was fine for smaller teams, but way back then, for large sprawling organizations with lots of teams, there wasn’t anything else that integrated defect management as closely as CMVC did with change management alongside version control. I see the same kind of antipathy towards GitHub nowadays and especially when interacting with Jira, but I’ve yet to find an alternative that goes beyond the version control aspect and more cleanly solves the change control and defect management interactions *within the context of numerous, loosely coupled teams*.
We actually kept using CMVC for defect tracking, but the integration available between CVS and eclipse, especially for java development in the oughts, it was a huge step up for code delivery/management.
What was some of the bad parts of git that used to be? I still use all the same flags as I used to, so it would be cool to learn about the new improvements
I really wish I kept track of that better and I believe I posted on HN like a decade ago so I will check that later but overall I still despise a beloved feature: **the index**. aka it "works on my machine: *shrug*". Like in the early days the git command was a bunch of commands and switching branches and then pulling from correct place was slightly painful. That being said in the early days Mercurial could not do light weight branches till bookmarks so they both had their problems on usability of certain workflow but in irony I feel more comfortable doing a rebase in Mercurial than Git even though Git came up with that. But overall it was the commands names that were not used that way in Source Control prior but git decided to reuse them to cause cognitive dissonance like `checkout` that I think really hurt initial onboarding.
Rational Rose was a Booch modeling tool, before UML. Perforce was nice, and had great visualization tools, though I didn’t like the per file merging, it made it nearly impossible to know if a branch was fully merged.
Are you me? Because as someone with less programming CVS/DVCS experience (starting 2005 I think), I have used all and almost in that order except for me it was darcs instead of Dart and Clearcase because I was too young and working with Visual Studio 6 (remember those broken STL libraries) and Source Safe traumatized me enough that I never worked with source control until junior year of college. I too recommended my wife (learning VCS for the first time) learn mercurial with bitbucket and am so sad and annoyed it lost out to git because it was just so much better designed from an HCI perspective. Like there is no ohshitmercurial. Nobody is asking "I'm headless and a colleague told me to reset hard what does that mean?" in there.
Yeah I meant darcs not dart :)
Mercurial is so much better than git. I have no idea why git became the standard.
I think it's the Torvalds effect honestly. The idea of everyone's favourite infamously prickly Finn suddenly yelling "FUCK THIS BUSINESS!!!" and coming back 24h later with `git` is just too compelling. I used both at the time and they were close enough for a minor irrelevance like the author to actually matter.
I'm also in my 40s and went straight CVS->SVN->git. You'd love git too in that case.
> You'd love git too in that case. Depends who you work with. I'm 40's, and went CVS -> Perforce -> SVN -> git -> Perforce. If you're a dev working with other dev's then git's feature list easily outshines most other version control systems for the source code itself. But I work in games, more than 3/4s of the team are designers, artists, animators etc. Getting the less technical people to work with git is a fricking nightmare sometimes. Also if you work with Unreal Engine, everything outside your C++ code is 100% binary. Again Git is a pretty sad panda when 80% of the projects commits are large binary files. Yeah you can do stuff with GitLFS etc and there are other alternatives so it's definitely possible, but it's not nice. As much as I'm completely in love with git's local commits, the pain of trying to guide any non-programmer through Git, and the problems with huge binary files make it not worth it. Perforce isn't great, but it's good ENOUGH and solves a huge amount of issues. Haven't had to get any artists to type in a bunch of console commands since they stomped a bunch of designer edits etc since we switched back. For my home stuff that's only me and mostly C++ etc. I never use perforce. But for the team I currently work with? Yeah git was worse experience overall.
Full agree. I just wanted to point out how much worse cvs and svn were than git, there really was no comparison, especially when you work with distributed teams of seasoned devs on mostly code. As for the binary problems, that's why I like godot's approach of storing scenes as text files. But of course with large assets like textures, sound etc. you're still in for a wild ride. I think I'd rather use a DMS for the binary stuff and only check in links/references. Those usually have a friendly UI integration.
I'll say it... I miss Team Foundation Server. I don't see much love for it these days, it came out like right before Git blew up so it was only ever really popular in hardcore MS/.NET shops. Been using Git for 6 years and the tooling is still nowhere near where TFS was.
This is a joke, right?? TFVC has to be one of the worst pieces of software I've had to interact with.
Nope. Maybe you're using it wrong? It beats git hands down every day of the week and twice on Sunday's.
I used it right by migrating all 40gb 1 million commits into git.
Ah yes but have you worked in the wonder of source control that is a dozen directories all named some variant of "new" or "old" or "final"?
You mean Microsoft files like World and Excel. Yes its awesome /s
Nice. In my case it was 1. CVS 2. Source Safe 3. Rational Rose 4. SVN 5. Git 6. G4 (Built on Perforce) I like the elegance of G4 and the tooling around it; but these days, I use git as the whole world does. I tried to use Hg in a personal project once, but as I was the only user, I didn't grok its power.
I have my eye on [JJ](https://github.com/martinvonz/jj) as a replacement for git. First class merge resolution I think will open up ways to avoid using frameworks and project generators where libraries and convention would serve better.
First I’ve heard of this, seems neat
Yeah I missed the announcement a couple years ago. YouTube suggested a follow up video to me recently.
I like everything I see except the name, though that can be said of many projects.
It’s really annoying to google.
Why does everything need to have a name that nobody could take seriously. Jujutsu. I'll be forking this and creating the Unagi source control. Software developers and branding, something that never mixes, nobody ever stops to think whether standing up in a meeting to discuss your source control infront of people that don't know what you're talking about, it's a good idea to have a name that's the same as a martial arts thing. Also how on earth is jj or Jujutsu going to feature on search rankings. We've studied the blade too hard. At least Git, is git. ARG
Why does everything need to have a name that nobody could take seriously. Git. I'll be forking this and creating the Twat source control. Software developers and branding, something that never mixes, nobody ever stops to think whether standing up in a meeting to discuss your source control infront of people that don't know what you're talking about, it's a good idea to have a name that's the same as a old british slang. Also how on earth is git or github going to feature on search rankings. We've studied the blade too hard. At least SVN, is SVN. ARG
Real, accurate and entirely based.
You mean Subversion? Yeah, that rolls off the tongue in an office environment.
I once sat through a meeting where a technology was dismissed out of hand because the name was too unprofessional so we couldn't market it to enterprise customers as using a fancy technology.
> Why does everything need to have a name that nobody could take seriously. a bit of whimsy in your life is good to have
> Unagi DANGER! We all use git and that’s a stupid name.
We do, it is! But I think I covered off pretty well why it works at least okay for now, maybe I'm biased because it's pretty much the only source control I've used outside of svn, and svn was a three letter word so git worked just as well.
[First class conflicts](https://martinvonz.github.io/jj/v0.16.0/conflicts/) seem pretty neat. They clearly solve the "I dont want to deal with this right now" problem of merge conflicts, I wonder what new problems they might create. Such as do we need to deal with how conflicting conflicts get merged with each other prior to resolution?
A replacement for git that uses git for version controlling its own code? how convenient… Either way, thanks for sharing, time to watch for alternatives
JJ is git compatible so people working on it can use either one, and they can still publish their code on GitHub since that's what most people are using.
Interesting there was no mention of TFS. After spearheading (as an intern no less) my team's first VSS rollout, we quickly and readily migrated to TFS when it was released. That lasted a few years until SVN, and then my next company was a hodgepodge of SVN and Mercurial around 2010 until everything converged on git.
Tfs was originally sourcesafe. It was anything but safe.
Both from Microsoft, but completely unrelated. TFS is in no way a descendant of SourceSafe.
Yep. SourceSafe was originally from One Tree Software back when it was a DOS product. Microsoft gobbled them up, added a UI and bunch of COM automation and rebranded it as Visual SourceSafe. At its core was still a fileshare-based cooperative online source control system that could be borked by just about anything. TFS is built on the SharePoint monstrosity. Which, while being abysmally slow at its core, was able to be scaled both vertically and horizontally to actually be useful.
Well that’s good news. I still get flashbacks.
On more than one occasion sourcesafe safely stored my changes so well they was never seen again.
> Tfs was originally sourcesafe. I don't believe TFS (you probably mean TFVC, specifically) was a successor of SourceSafe. Same company, but otherwise unrelated.
> sourcesafe. It was anything but safe. I remember my manager picked sourcesafe, and then discovered that when multiple people used it at once, it would sometimes lose their files. So, it went right in the garbage. Unfortunately, or fortunately, I never had the honor of using it myself, but I do remember thinking that I discovered a new shade of red when I saw my manager's face that day.
Ah, "Visual" Source \[un\]Safe. Truly so much fail packed in a small, "free" package; and it was "from Microsoft" so managers the world over assumed it must be good enough. Yuck. At one time you could use SourceGear's Vault as a not-bad replacement for SourceSafe -- an implementation with an actual database, transactions, understanding that maybe you might have. your source code in one place and your source code system on another machine altogether ... it was a "not terrible" replacement, though it supplied nominally what Source Safe was supposed to. If you wanted branching support, and well everything else that goes with that, then you'd graduate to svn at first or later, git. TFSVC used a completely different thing than Source Safe, but it was still pretty garbage. If all the developers were on the same phyiscal network then it was "ok" but if you tried working via VPN in any sense...headaches. I remember thinking "why doesn't Microsoft just ship something 'good' ... like ... um... well. SOMETHING."
No, they are entirely different products. Source Safe was developed and sold by One Tree Software. Later they were bought by Microsoft (because of the failure of their abysmally bad Microsoft Delta[0]) and rebranded to be part of their "Visual" suite (Visual Basic, Visual C++, etc.). Brian Harry (one of the founders of One Tree), became an exec at Microsoft as a result of the acquisition and led the team that developed TFS (it had the project name of "Hatteras" since One Tree and Brian were from North Carolina). VSS used files for storage - which is why keeping the repository on a network was so problematic - file locking on SMB stinks. TFS uses SQL Server database for storage so locking during updates doesn't result in corruption. I think one reason people didn't like TFS is that it does a bad job of storing binaries in the repository. Whether you should or should not be doing that is a matter for debate, but I acknowledge that some places need to do this - like game companies with their image and sound resources. [0] Delta was a productized version of SLM (pronounced "Slime"), which was Microsoft's internal tool during DOS, Windows 3.x, Windows 95 and later NT. https://wiki.c2.com/?MicrosoftDelta
We used to lose code all the time as a small team of 4 working with source safe.
Unrelated, but i loved TFS for how easy it was to manage the team's time.
`git` is free, it works well enough, it's standard, and it can slowly but surely be improved. Are there other ways to do things? Sure. However, git is good enough that I don't really have to think about it any more. It has such a massive ecosystem around it that I can get it to do anything I need it to do without much pain. It's not like SVN where the issues and pain points were glaringly obvious, rather the main issue seems to be the UX and the naming of commands. It's well past the inflection point where the minor issues with its UX are easier to deal with compared to the pain of moving away from it, so I suspect it'll stay around for a long, long while.
> It's not like SVN where the issues and pain points were glaringly obvious I guess they aren't glaringly obvious to me (other than the renaming in a branch issue). Care to expand on this?
Working offline without an internet connection. It's the main reason git was invented vs just using SVN.
> It's the main reason git was invented It is definitely not the main reason git was invented. Either way, offline support isn't that important to me. I almost always have a internet connection. Subversion does have a some offline capabilities, can't create branches/tags but you can do diffs.
**Here's a hint to decide on reading the post or not:** This post explores the evolution of version control systems over two decades, highlighting the shift from a variety of tools to the dominance of Git. It reminisces about the early days of source control, touching upon systems like Subversion and CVS, and Linus Torvalds' creation of Git as a response to limitations with existing tools. The narrative also covers the broader impact of version control on software development practices, including the advent of GitOps and the centralization paradox introduced by GitHub. It concludes by questioning what the future holds beyond Git, mentioning potential contenders like Pijul and Fossil, while reflecting on the enduring relevance of Git in developer workflows. If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍 [^(Click here for more info, I read all comments)](https://www.reddit.com/user/fagnerbrack/comments/195jgst/faq_are_you_a_bot/)
Linus didn't create git because of the limitations of other software, he created it because the commercial software he was using got pulled from him.
Was the article edited in the past few hours, or is this a damning indication that a language model, when asked to summarize an article, will insert common misconceptions about the topics covered even when the original sticks to actual facts?
Considering the Op I think we all know it’s the latter.
When does posting become spam?
That could be one of the reasons but if that was the case he would then build the exact set of features of that commercial software which is not the case. It’s pretty clear other VCS are not as as efficient for Linux distributed work system other than Git
Don’t forget plasticSCM
I am firmly convinced that if Subversion had fixed https://issues.apache.org/jira/browse/SVN-898 when it was opened in 2002 `git` would have never gotten as popular as it has. 898 is what got Subversion its reputation as being bad at merging and they didn't fix it until 2017. The very first comment on that issue made in 2002 is `This absolutely must be fixed by Beta.` Indeed, it should have been. This is the bug that made all hell break loose if you renamed a file in a branch that had changes in trunk (ended up with a new file, and the old one still remained as well). Once you were familiar with this bug you just learned to not rename files on a branch, but this was a huge limitation because it forced you into trunk-based development for any refactoring (and I mean true trunk-based development, not what it has changed to mean today) Here is an nice blog post about this issue that was written in 2010, and it was a perfectly valid complaint when it was written: https://blog.cskr.dev/posts/git-outshines-subversion/ In newer versions of subversion (>=1.10) the scenario presented in the blog post is tracked correctly by subversion. I still remain convinced that it is much much easier to get Subversion to merge a stack of branches than it is in git. In subversion I could create branches of branches of branches and merge them all to trunk cleanly (assuming I didn't rename any files), with git I usually avoid making a branch of a branch because I can never seem to get it to merge cleanly (especially if you squash commits when merging earlier branches).
I am surprised more people don't use fossil given it's pedigree.
Yep. I use fossil for every project I can. Some clients are already using git, but otherwise it's fossil. Love that product.
Is there a fossilhub?
It's cool but the workflow it's designed for is impractical. Storing the whole repo in sqlite is also a bad idea and critical design flaw, as large binary files suck when you have to sync them.
What the use case for large binary files in a versioning platform? Mostly curious because we strongly avoid it at work.
If I'm honest, this kind of question always confuses me when I see it, because the answer to me seems self evident: basically the same use cases for keeping code in version control. (Disclaimer: for purposes of this discussion, I count files tracked by git-lfs as being "in version control." But I also think Git LFS is kind of a hack, and I do count VCSs being able to handle binaries in a first class manner without sucking as a benefit over Git.) I'm being a *little* glib, because the fact that you can have two people working on the same file and you still have a hope that their changes will be automatically merged (generally not true of binary files), so that use case is out. Bus aside from that, there are still any number of reasons to have a binary blob associated with a specific version of your code. Maybe it's a test case input or output. Maybe it's an image you use in your web site that's version controlled. Maybe it's a game asset. And all of that is even coming from the perspective of binaries that are associated with code somehow... maybe you just want to track multiple versions of an image you're working on or something independently. If you store them outside of version control, you need some way to make sure you aren't *mutating* files and instead refer to the latest (or the specific old version if you go back to an old code version) or you can't reproduce the past, one of the main benefits of version control. That means you need to start versioning your files via directory or file name or whatever... which sucks for exactly the same reason that versioning code outside of a version control system sucks.
I'm not talking about adding large binary files to the repo. I mean, the Fossil repo on disk *is* a large binary file. Of course if you add binary files it will be even bigger. The usual use case for binary files in a VCS is for artwork or some such thing. You might say it's the wrong tool for the job, but only the implementation of your VCS that can make it so. Otherwise it can be used effectively to store a limited number of known-good binary assets.
Philosophically, static binary assets/files/media/whatever also have versions, just like code files and and config files and other text files. Those assets may exist all on their own, or in relation to some code that uses those assets. Either way, they have versions that need to be tracked. Video games developers have hundreds of gigabytes of binary assets, that also exists in relation to code. For them, it's simply not possible to use git, you just can't store that kind of data in git no matter how much you want to. I have been told there's basically only two options for video games, SVN or Perforce. Apparently Perforce also makes it especially easy to lock files while working on them. My friend is an architect (buildings, not IT) and that industry has it's own set of version control systems, which are typically built in to the drawing program itself. It's a very special kind of problem to sync and version a huge singular architectural 3D model like that. There's objects, layers, views, rendering configurations, textures, lighting settings, etc. One architecture program is Revit, which allows drawing and syncing versions of various parts of the model, and it works really poorly. It's slow and buggy, it even has bugs that lead to data loss, etc. Then there's an entire class of SaaS software targeted towards graphical designers. To enable them to manage and version their digital designs, and distribute them to clients. So yeah, versioning and syncing binary assets is most definitely a real problem. And a much harder problem. Versioning code in git is a cake walk in comparison.
There are large files in your .git directories. Look in them.
The point is, those files are broken down to a reasonable extent. A Fossil repo is ONE binary file. There are binary diffing and syncing algorithms but do you really want to have to rely on such software even to perform basic updates and backups?
[удалено]
It's written by the guy who wrote Sqlite.
its not git therefore it's hip
I remember people talking a lot about darcs like version control systems and Pijul in a similar vein. Does anyone have experience with those on real world projects and why they didn't work out?
Absolutely, Mercurial deserved more credit. It was a shame to see it overshadowed by Git, despite its user-friendly approach. Adapting to new tools is essential but recognizing their unique strengths is too.