Live data from Hacker News

Ask HN: Can we do better than Git for version control?

news.ycombinator.com

131–140 of 309 posts

Re: Ask HN: Can we do better than Git for version control?

#131
post #77

A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen. I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare…

While I feel like this is generally true for most programmers and knowledge workers, Git is absolutely not suited to the workflow of several industries, including the one I work in: games. Working with an engine like Unreal Engine for a project of any reasonable size requires working with both hundreds of thousands of active files (my current project's repo's HEAD has ~400k) and hundreds of gigabytes of active files,…

This could be solved with references rather than copies if your tools integrated them. e.g. dependencies can be ref'd with source/name and version. To ensure availability all such used blobs could be stored efficiently elsewhere and versioned.

It's great that Perforce works and I've heard others in the graphics field using it, so it satisfies a need. Don't know if/when it would be a general need for say GitHub users.

Re: Ask HN: Can we do better than Git for version control?

#132

Have heard of some FAANG (meta, google..) moving to Mercurial. Any merit in that?

yep both extended it and have versions that can work against GitHub/git servers. sapling scm from meta has I think the best cli and VS code UX https://sapling-scm.com/ jj from google is also mercurial derived with very similar cli features like histedit and has support for deferring conflict resolution https://github.com/martinvonz/jj

To clarify, jj is not derived from Mercurial, but it's heavily inspired by it. The current DVCS solution at Google (called Fig) is based on Mercurial, however. But we're hoping to replace it by jj.

Re: Ask HN: Can we do better than Git for version control?

#133

Earlier quoted context omitted.

Git keeps the entire history on your local machine, this becomes a problem if your project grows to several hundred GB (not untypical in game dev). Even SVN was much better for working with large repositories, you only needed a big server. Git is quite nice for "source code only projects though".

Does Git LFS help with this problem?

Not Git LFS, but Git VFS, now replaced by “Scalar”:

https://github.com/microsoft/scalar

Re: Ask HN: Can we do better than Git for version control?

#134
post #77

A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen. I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare…

That's what i liked about git too. It felt like a powerful, ready to use tool. CVS and SVN were more bureaucratic, slower and limited. Took zero second for me to drop everything else.

The underlying model is alien to many, it requires non black box approach to get out of pits sometimes but to me it's always worth knowing.

The only decision I dislike about git is the soldered staging area idea. There's a reason why most people end up stashing 109 times a day, and I think there's a golden idea in merging the two

Re: Ask HN: Can we do better than Git for version control?

#135

Earlier quoted context omitted.

Do it then. Many have tried. All have failed. Talk is cheap.

>Do it then. Many have tried. All have failed. Talk is cheap. I'm, just like many other people using GitHub Desktop (or Git Kraken or Git Extension, but I dont like this one) when I'm working in GUI environment, that's proof that it is possible. The problem with creating 3rd party tool that's CLI wrapper is that you cannot rely on it being installed on the system. That's why such solutions usually fail - because you…

Is gitk still a thing that's available with git? Not as full featured but great for viewing and good with many commits/files.

Re: Ask HN: Can we do better than Git for version control?

#136
post #66
post #9

Jujutsu version control system looks very promising in the way it brings the best of other DVCS'es together and innovates on various concepts. It has been discussed a number of times on HN before. [0] https://github.com/martinvonz/jj [1] 4 montsh ago, 261 comments https://news.ycombinator.com/item?id=36952796 [2] 2 years ago, 228 comments https://news.ycombinator.com/item?id=30398662

Surprised this is done in Rust. I could never imagine not doing the v1 of something like this in Python or similar, to be able to change things quickly. Maybe the design was very clear on the person's mind.

Python certainly lets you change things quickly, because it does not let you automatically enforce any invariants; this is why it lets you get into such extraordinary inconsistent states so easily! I personally could never imagine trying to make a jigsaw out of jelly because "it's v1 and I'll make v2 properly".

Re: Ask HN: Can we do better than Git for version control?

#137
post #66
post #9

Jujutsu version control system looks very promising in the way it brings the best of other DVCS'es together and innovates on various concepts. It has been discussed a number of times on HN before. [0] https://github.com/martinvonz/jj [1] 4 montsh ago, 261 comments https://news.ycombinator.com/item?id=36952796 [2] 2 years ago, 228 comments https://news.ycombinator.com/item?id=30398662

Surprised this is done in Rust. I could never imagine not doing the v1 of something like this in Python or similar, to be able to change things quickly. Maybe the design was very clear on the person's mind.

The current DVCS solution at Google is based on Mercurial, which is written in Python. Having worked on that for many years, I didn't want to write jj in Python. We've had problems with the performance of the current solution. Also, as others have said in sibling replies, refactoring Python is not fun due to lack of static types (I know it's gotten better).

Re: Ask HN: Can we do better than Git for version control?

#138

Earlier quoted context omitted.

>I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. I disagree, really. There is not fundamental reason why you cannot have user-friendly UI for 98% of the cases and some "advanced" for those 2%. Just like GUIs have "advanced" settings, the CLI can have well designe…

Do it then. Many have tried. All have failed. Talk is cheap.

Magit is great. So not all have failed.

Re: Ask HN: Can we do better than Git for version control?

#139
Really depends on "what".

I use a wiki which internally uses RCS, but you never see it. The only reason I even know is that I needed to scan older versions of some assets and it was straightforward compared to what you'd expect with Git. (Other bonus, attachments and meta pages are stored as actual files. With a little bit of code you can cobble together an automated page builder for e.g. physical assets.)

I consider rsync --link-dest a version control system.

Re: Ask HN: Can we do better than Git for version control?

#140

I more or less consider it a solved problem. You're mostly going to hear from people here who are annoyed with Git or otherwise more interested in the topic of version control than the median developer. For me, I think it provides a quite robust and well thought-out set of primitives, and then composes them upwards in ways which are about as good as one can expect. Some stuff obviously isn't well supported. Using the…

>I think it provides a quite robust and well thought-out set of primitives

The existence of the staging area is a poorly thought out part of the design. No other VCS uses it because it was a bad idea that makes the simple case of commuting changes more complicated.

>Fossil would be my next bet. I'm waiting for someone to make an archaeology.co to rival GitHub.com for it.

Which is exactly why fossil will not be the next big VCS. Ignoring all of the projects on Github add forcing people to move to a less featureful, less integrated, less familial forge just to use a new source control system is a hard sell. The approach of Sapling and Jujutsu where they support the git protocol so that they can be used Github will make them much easier to adopt since it can happen incremenetally and it fully replace git for people.

Post reply on HN