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

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

news.ycombinator.com

Post reply on HN
Print view View original

261–270 of 309 posts

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

#261

Post by kevincox »

flohofwoe wrote: post #96
Apreche wrote: 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…

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".

This is true, but it is technically an implementation issue. Git supports shallow and narrow clones. The data model works fine with only partial local knowledge. That being said the "check out all files to disk" approach does have fundamental limits for many operations. It is one of the very few operations that are linear with the tree size but it isn't fundamental to the abstract model of Git. To solve this something like a virtual filesystem that fetches new data as required and tracks changed files can make almost all daily operations scale with the size of the patch, not the size of the tree. The data model for this tracked change would be basically equivalent Git's index structure, just applied to the working tree instead of leaving the working tree on a general purpose filesystem.

That being said the unfortunate truth is that many, many, many users of Git rely on the implementation as the API, directly reading and writing to all corners of the `.git` directory. So even if the core command could support something like this (or a wrapper could be provided) it would likely run into a lot of tooling issues.

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

#262

Post by slalomskiing »

withinboredom wrote: post #185
dafelst wrote: post #117

Earlier quoted context omitted.

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 is a solved problem with git. I’ve worked on bigger projects than yours with histories that are so big you can’t clone them if you wanted to. I’ll make a note to drop what to google for tomorrow, but basically the history is fully available but git knows how to query it over the network. When you open a file, it loads it over the network. Remote build systems do your builds. Most of this was built by Microsoft t…

> Add to that the necessity for less-technical people (artists, designers, VFX, audio, etc) to use it

How is that solved with Git?

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

#263

Post by slalomskiing »

penguin_booze wrote: post #165
cflewis wrote: post #161

Earlier quoted context omitted.

This post is a terrible failure of imagination that would make one stop language development as C because it was so much better than Assembly. If you have no problems with Git, then I’m happy for you. I certainly have problems with Git, eg its inability to handle large repositories meaningfully (enjoy a Chromium checkout!), the arcane CLI commands, the shut-your-eyes-and-hope of moving commits between branches and ot…

> its inability to handle large repositories meaningfully Out of curiousity, what other SCM tools can pull this off better?

Almost every big game studio uses Perforce

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

#264

Post by darose »

Apreche wrote: 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…

> Git has no such problem. There’s nothing it can’t do.

It can't display me the branch I'm working on, starting from the commit that began the branch, until the last commit. (Or if it can, I have no idea how to do it.)

This isn't a functionality issue, but rather a conceptual one. Git just fundamentally thinks of branches differently than I do. (And, maybe most humans?) To me, a branch begins ... when I branch it. To git, a branch begins ... at the very first commit ever in the repo, since they consider commits that were made before the branch point to still be part of the branch. The branch point then is just another commit to git - and not even one that they think is important enough to highlight. But without any ability to clearly identify the branch point, you can often find yourself looking through a forest of commits that are irrelevant to what you're really searching for.

I spent the better part of an hour the other day trying to figure out how to identify my branch point. (For the record, the best solution I eventually found was: cat .git/refs/heads/.) Just my $0.02, of course, but IMO this is absurd - and a big feature gap / user friendliness issue with git compared to other VCS's.

IMO git is just another step in the evolution of VCS's, and not necessarily even one of the better ones. Its concepts, functionality, and feature set are focused primarily on distributed development and multiple people maintaining different source trees ... which is fine for the Linux kernel and other projects that heavily use that use case. But many/most projects don't work that way, and for them a centralized VCS is sufficient. I have no doubt that a better VCS will come along and replace git one day.

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

#266

Post by CrimsonCape »

Git is the product of an engineer, not a designer. Whereas engineers glue the parts together and make them work, the designer looks at the parts and questions if they are polished as to the intent and the logic.

I think git escaped to the public before having a designer's refinement. Users need to learn about the glue and speak the glue language to git to make it work.

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

#267

Post by mmis1000 »

cflewis wrote: post #161
Apreche wrote: 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…

This post is a terrible failure of imagination that would make one stop language development as C because it was so much better than Assembly. If you have no problems with Git, then I’m happy for you. I certainly have problems with Git, eg its inability to handle large repositories meaningfully (enjoy a Chromium checkout!), the arcane CLI commands, the shut-your-eyes-and-hope of moving commits between branches and ot…

There is a major misconception that you move your "commit" around. Actually, each commit in the git history refer to a specific directory state and parent of such commit. You can't meaningfully "move" a commit directly. What the cherrypick and rebase does is.

1. The client diff content of your commit with previous one. 2. Apply such diff on content of another commit. 3. Create a new commit with the old commit message/author of commit in step 1.

And that is also what make git work for everyone, because it is simply a directory that contains tons of new_new_updated_project on steroids. It's up to you to decide what to do with it.

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

#268

Post by DemocracyFTW2 »

thfuran wrote: post #122
DemocracyFTW2 wrote: post #72

> Or is it a solved problem and Git is the endgame of VCS I've read so many comments to the effect that "X is a solved problem" when it clearly wasn't that I've come to conclude that the phrase means the opposite of its surface value... I'm pretty sure that Git is not the end-of-line as far as VCSs go. Whether I will ever change my VCS, again, ever, that is an entirely different question. I've been through so many of…

>Mercurial, because hey it was written in Python, so must be good, right? right?; Well, I can't really say that that's why, but yeah. Mercurial's pretty great.

Maybe it's now but I hit upon some snags / bugs back in the day (a fairly long time ago, >> 10 years)

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

#269

Post by Smaug123 »

yencabulator wrote: post #255
Smaug123 wrote: post #128

Earlier quoted context omitted.

"Fine" is not "optimal". The mere fact that something does the job does not make it the best possible thing that does the job. The most trivial example of a thing that is wrong with Git and which no amount of getting better with the tool can possibly help is "once you generate a conflict, you cannot perform any other versioning operations until you fix the conflict or revert". In particular, for example, you cannot c…

Maybe you want more local clones (git clone -l -s) or to use worktrees, so you can leave a merge conflict pending in one of them? Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved. If you really want that, maybe you want to just commit the conflict markers and come back later; rebase the commits together once you're all the way done.

> Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved.

Exactly my point: this is a fundamental limitation of Git for which there is no good workaround. It's not inherent to the domain, but is a limitation of Git. Pijul (for example) considers conflicted states simply to be normal.

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

#270

Post by afjeafaj848 »

Brian_K_White wrote: post #228
dafelst wrote: post #117

Earlier quoted context omitted.

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 sounds like a case of using excel as a db. Holding a hammer by it's head a declaring it unfit for normal people to paint with.

I also work in games and everyone I know uses Perforce for the reasons mentioned above

Have you considered that maybe they just have a different use case than you?

Post reply on HN