Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Version control second coming

psantosl.github.io

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Version control second coming

#61

Post by gmueckl »

dxdm wrote: post #36
gmueckl wrote: post #20

It's great to see some moves to break up this great calcification around git. Gut greatest contribution to version control was stagnation. The space was evolving with great fresh ideas before git became a quasi-religion among the early adopters because Linus made it in a day and therefore it must be great or something. I'm exaggerating somewhat, but the zeal of some people back then was next level annoying. Beyond th…

I don't think jujutsu is proprietary (unless you want to redefine that term). Source is freely available, and it uses Apache License 2.0. While you're right about the disadvantages of git, pretending that it became ubiquitous because it "became a quasi-religion because Linus made it in a day" is selling short its advantages. If you think about it for even just a little bit, it should be obvious what a simplistic stat…

The combination jujutsu/piper is proprietary. As I understand it, sapling as released is also not the entire internal system used at Meta.

Git was an improvement over SVN in some aspects, but a monumental regression in others. There are no two ways around that.

Mercurial is better than git in a bunch of ways. It is much more usable because it has way fewer footguns. But it has some of the same shortcomings as git when compared to SVN. I won't call it perfect.

The reason we didn't get svnhub is that some git fanboy nabbed the domain and essentially said "you shall not have it". Joking aside, there was Sourceforge with working SVN support. But I would say that Sourceforge lost market share for a lot of reasons, not all of them technical. Wrapping Windows downloads in adware installers was only one of those many crazy unforced errors.

Am I bitter? Maybe, because I have to use tools that could be so much better. I've experienced better and every time I am forced back to git, it feels a bit painful because I know what we could have instead. If am bitter, it is because of my experience with a wide range of tools.

Re: Version control second coming

#62

Post by theandrewbailey »

monster_truck wrote: post #28
rjsw wrote: post #18

People complained about having to use ClearCase back then, it wasn't just the price that was wrong with it.

I helped swap a mess of ClearCase & Subversion over to git (early 2010s). What a fucking cursed piece of software! Will admit it got exactly one thing right, which could absolutely justify everything else (including the price) for a long time: Software Bill of Materials, which is non negotiable in a lot of more serious/heavily regulated development contexts That still didn't excuse the hacked together pile of ruby sc…

My first programming job was an internal line of business application at a mortgage vending company. There was an uncomfortable amount of time wasted waiting for someone to do something in ClearCase so I could commit. I've turned down interviews solely on the basis that I would be using that dumpster fire of lost productivity and UX from hell.

Re: Version control second coming

#63

Post by dxdm »

gmueckl wrote: post #61
dxdm wrote: post #36

Earlier quoted context omitted.

I don't think jujutsu is proprietary (unless you want to redefine that term). Source is freely available, and it uses Apache License 2.0. While you're right about the disadvantages of git, pretending that it became ubiquitous because it "became a quasi-religion because Linus made it in a day" is selling short its advantages. If you think about it for even just a little bit, it should be obvious what a simplistic stat…

The combination jujutsu/piper is proprietary. As I understand it, sapling as released is also not the entire internal system used at Meta. Git was an improvement over SVN in some aspects, but a monumental regression in others. There are no two ways around that. Mercurial is better than git in a bunch of ways. It is much more usable because it has way fewer footguns. But it has some of the same shortcomings as git whe…

Well, then I'm sorry. Your issue seems not so much that tools have shortcomings, but rather, that you seem to focus on these shortcomings so much that everything looks like crap. Maybe not in general, but at least in relation to VCSes, it sure seems like you're wearing some brown-tinted glasses, so to speak.

As a point in case, it's certainly interesting to see you completely disregard jujutsu because it happens to also work (optionally!) with a proprietary backend, when its most useful feature is that it makes working with git night-and-day better, nothing proprietary required. This thing could be a ray of light for you, but for some curious reason, you seem to go out of your way to ignore it.

I mean, it's definitely possible that you think to this day that SVN was the bee's knees and its demise in favor of git or mercurial made us all poorer, but that's certainly a rare perspective. In that context, I'm also finding it hard to reconcile your initial statement around the calcification in VCS land, and now it sounds like you would have preferred to stick with SVN instead.

I'm sure you can give me a rationale for it all, but I wonder how much of it will be just picking rotten (or declared-rotten) cherries out of an otherwise tasty pile. If you stack up the present against a rosy-tinted version of the past and some inexistent pie-in-the-sky, it's no surprise it comes up wanting; but that's just a way to make yourself unhappy, really.

Re: Version control second coming

#64

Post by rhdunn »

vanderZwan wrote: post #42
teiferer wrote: post #10

2/3 down the article I gave up. What are you trying to tell me? What is this revolution about? How are agent things fundamentally different and how are they being solved? What is this "second coming"? Also, why "second"? Was git the first? But then what about all the other things before it? CVS was huge before, for better or worse.

The author has a severe case of being oblivious to the fact that not everyone knows what they know, or views the world the way they do. As shown for example by their assertion that "we all stopped coding manually around December 2025" , as if AI critics don't exist. As a result you have to look at what they share about themselves to infer where they're going with things, because they never explicitly state it. All tr…

I'm not an AI critic (I use it for autocompletions and asking some questions) but still write my own code.

I'm not sold on the agentic workflows that AI labs are pushing and haven't yet figured out if/when/how to integrate it into my workflow.

There are two general things I'm weary of with agentic workflows compared to the chat-based workflows:

1. the agentic workflows are much more inclined to go and do the thing rather than involve you in the loop -- e.g. if you are trying to design/plan something;

2. the agents are happy to go and run any command -- you can get them to prompt to confirm the action, but they could easily do something like wipe your home directory, install a random package, or something else.

Re: Version control second coming

#65

Post by Supermancho »

vanderZwan wrote: post #42
teiferer wrote: post #10

2/3 down the article I gave up. What are you trying to tell me? What is this revolution about? How are agent things fundamentally different and how are they being solved? What is this "second coming"? Also, why "second"? Was git the first? But then what about all the other things before it? CVS was huge before, for better or worse.

The author has a severe case of being oblivious to the fact that not everyone knows what they know, or views the world the way they do. As shown for example by their assertion that "we all stopped coding manually around December 2025" , as if AI critics don't exist. As a result you have to look at what they share about themselves to infer where they're going with things, because they never explicitly state it. All tr…

> "we all stopped coding manually around December 2025", as if AI critics don't exist.

It was obviously a generalization. The number of AI critics (which eschew AI for coding) are a minority. I would say tiny minority at this point.

Re: Version control second coming

#67

Post by nosioptar »

black_knight wrote: post #6
bolangi wrote: post #2

Dreaming of "virtual filesystems everywhere". Hmm, sorta sounds like Plan 9. Great to have an inside view of wrangling technologies for these behemoth data sets.

Plan 9 had such a powerful model for networked systems using these virtual file systems, it sounds like a fairytale! Oh, want to use that other machine as a gateway? Just mount its /net. Oh, want to route audio through another machine? Just mount their soundcard into your /dev. Oh, your machine is too puny to do the task at hand? Just run “cpu thebigmachine” which transplanted your entire environment over there (all…

I'd love a Plan9 with a keyboard driven UI.

Re: Version control second coming

#68

Post by bob1029 »

MindSpunk wrote: post #49
bob1029 wrote: post #33

It sounds like the author went through a lot of pain to avoid using git+lfs or perforce. I use git+lfs for unity projects and it works out great. If I had a real studio I'd buy some perforce seats. Reinventing the wheel like this is quite exhausting. There are options that are proven to work. AI authorship does not fundamentally violate the idea of some thing owning a specific commit. We don't need new schemas in our…

From my experience Git LFS is extremely brittle and will break your local check out if you so much as breath on it wrong. Perforce is an expensive solution to the problems of LFS, and I've yet to find a workflow as powerful as my git workflows for managing code. I don't really see what the article is talking about as the future, but if P4 or Git LFS is the best we can do as a species then we're doomed. All VCS option…

Git and P4 are not meant to be directly competitive here.

Git is for teams that are distributed across space & time. P4 is significantly better at centralized teams who work in the same physical office.

I am curious what in LFS is breaking for you.

Re: Version control second coming

#69

Post by snovymgodym »

I think this article conflates GitHub and Git a few times, though the author definitely knows better.

For better or for worse, I don't think Git is going anywhere. A lot of the recent developments in source control amount to providing a better user experience for git repos.

We might well see companies move away from GitHub as source of truth in favor of alternate forges with better SLAs or self-hosting, but dethroning git itself at this point feels very unlikely.

That being said, Git has two big weaknesses: non-text files and handling massive repositories. This is why you see continued use of centralized version control systems (e.g. Perforce, ClearCase) at organizations that need these things. Git LFS tries to address large non-text files, but in my experience teams tend to prefer VCS systems that handle this natively.

At a few big tech companies that decided to use huge monorepos 20 years ago, they've since hand-rolled custom non-git version control systems tailored to their unique scale. These systems usually work by combining a centralized version control server (similar to SVN or Perforce) with a virtual file system that selectively populates code paths based on the current checkout.

But the vast majority of orgs don't need massive monorepos or large amounts of non-text files checked into their repo.

Re: Version control second coming

#70

Post by gmueckl »

dxdm wrote: post #63
gmueckl wrote: post #61

Earlier quoted context omitted.

The combination jujutsu/piper is proprietary. As I understand it, sapling as released is also not the entire internal system used at Meta. Git was an improvement over SVN in some aspects, but a monumental regression in others. There are no two ways around that. Mercurial is better than git in a bunch of ways. It is much more usable because it has way fewer footguns. But it has some of the same shortcomings as git whe…

Well, then I'm sorry. Your issue seems not so much that tools have shortcomings, but rather, that you seem to focus on these shortcomings so much that everything looks like crap. Maybe not in general, but at least in relation to VCSes, it sure seems like you're wearing some brown-tinted glasses, so to speak. As a point in case, it's certainly interesting to see you completely disregard jujutsu because it happens to a…

What's wrong with stating my opinion when it's relevant to the topic?

I feel like you are somehow irritated by what I said. Are you personally invested in this discussion somehow?

You have a point in calling me out on jujutsu. I haven't spent enough time looking into it because I have been busy with lots of other things. And I haven't seen any forge-like tooling around it, which further reduced this in my personal priorities. I also got the impression that jujutsu by itself is less scalable than the proprietary jujutsu/piper combo.

The other VCS that I should look into more is Lore. But again, time has been a limiting factor for the past year or so.

You know the really funny thing? I talked to many people with similar skills and experiences as mine and we all essentially have very similar issues with the established open source VCSes.

I had a list of missing features here and it's long and it's boring and I deleted it because it's the kind of stuff that tedious to litigate and what's the point? I'm not here to make anyone switch to something else. I really just hope that we can move past git-as-default into a better era. That's all.

Post reply on HN