Live data from Hacker News

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

news.ycombinator.com

111–120 of 309 posts

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

#111
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…

The git model has fundamental limitations because it saves snapshots rather than changes, and doesn't capture some metadata changes like renames. A tool like Darcs or one of its spiritual descendants will have fewer merge conflicts than git. Totally agree on your main point though. The benefits of switching are far lower than the costs.

>it saves snapshots rather than changes

Once you understand this, GIT makes a whole lot more sense. The trouble with failed merges is an artifact of trying to appear like it tracks deltas. Merge conflicts when you're the only programmer on a product (but have multiple computers) are maddening.

I blew away .git and everything in it, restarting a repository, more than once because I couldn't resolve a merge conflict, before I learned that simple fact.

I've got from .zip files of my source code on floppy disks, to SVN, then Mercurial, and finally GIT. GIT is amazing, though the UI is a pain, as most agree.

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

#112
post #90

The only thing I wish git handled better out of the box, with without any flags/setup, is large/binary assets. LFS is ok but it still feels like a kludge to me. The cli does not bother me, there are many tools that offer alternatives/overlays/UIs. Not saying it is perfect or even good, but it's good enough - for me at least.

exactly right! lfs is "kinda okay?" at best. i just wish binary support was just part of git natively.

honestly keeping the large binaries as loose objects would be fine except for performance. which should be something that could be improved with cow filesystems (lfs does use this, but limited by what git's implementation can support)

or it may be enough to incrementally improve lfs, i do see that ssh support is showing up which might help a little. need to do something about smudge/clean filters too, which would require new support in git itself.

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

#114
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

I tried this, and I loved it. It works very well with my workflow.

Perhaps the author can explain - when you clone the repo with

jj git clone

It pulls down a branch that is auto generated like pull-(hash)

I can’t understand how not to get that corrupted so when I do a jj log, I get very weird branches or heads or I’m not sure what.

Another way to say it is that everything works great until I have to pull down the repo from another machine - then the branch history is not what I expect. And I just couldn’t make sense of it or get it to square with what I expected.

I actually created a custom GPT and fed it the jj code and documentation to try and get it to explain it to me to no avail. Jj is so good, I’m willing to give up IDE integration with git if I could just crack this nut.

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

#115
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…

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

There's a lot of "useless" complexity in the Git UI. The naming of the commands and the underlying concepts are quite inconsistent. The commands themselves are inconsistent. It's rare to see somebody, even git fans, to dispute that the UI is far from optimal. And the warts in the UI are being improved.

These UI warts start to become invisible when you get used to them, but e.g. when teaching git they become painfully obvious again.

The underlying git architecture is simple and it's the simplicity that makes git powerful. Powerful tools don't necessarily need complex interfaces. In fact power often comes from simple interfaces that compose well.

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

#116

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?

Have seen various teams have major issues with LFS - becoming quite a support overhead to keep art teams productive.

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

#117
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, many of which are many GB on their own. Our repository (in perforce) is currently in the order of 10TB.

Git, even with LFS and partial clone and shallow copies and fsnotify just falls apart at this scale. Add to that the necessity for less-technical people (artists, designers, VFX, audio, etc) to use it, and it is really just a non starter.

I absolutely loathe Perforce (having used and occasionally admin'd it professionally since 2007), but I begrudgingly admit that is is currently the only publicly available VCS that can fulfill all of the requirements of this industry in a practical way. Plastic and the others just aren't there yet.

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

#118
My experience is that the power of any technology unfolds gradually - with git it's like okay let's master the commands for a single repository on a single server for a single user up to a certain level of adequacy. Then (depending on need), let's add multiple repositories on the same single server for the same single user. Then add multiple servers (including a git remote server). Then add multiple users ... etc ... of course the magic of git is you can unfold those needs in any sequence. Often when I find I do not understand something (that I thought I understood), I go back in scope to an earlier unfolding, eliminating other factors.

I'm sure git can be improved, but I think the biggest improvement comes from the user being improved with their understanding of the scope of capabilities. I have yet to see a good tutorial on this (among the plethora of git tutorials out there). This reminds me of the (excellent) video where the "Harvard Professor Explains Algorithms in 5 Levels of Difficulty" [1]

[1] https://www.youtube.com/watch?v=fkIvmfqX-t0

I would love to see a Channel where that is the entire theme - explaining everything in 5 levels of difficulty.

All this being said, at each of the "5 levels of difficulty" of git, are there improvements to be made. I'm sure there are. It would be good to focus the answer on each of those levels.

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

#119
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…

The git model has fundamental limitations because it saves snapshots rather than changes, and doesn't capture some metadata changes like renames. A tool like Darcs or one of its spiritual descendants will have fewer merge conflicts than git. Totally agree on your main point though. The benefits of switching are far lower than the costs.

> doesn't capture some metadata changes like renames

If you rename the file using git and that is the only change in your file, then it works:

  git mv oldfile newfile
Commit that change and the rename is in your history.

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

#120

Earlier quoted context omitted.

Does Git LFS help with this problem?

Have seen various teams have major issues with LFS - becoming quite a support overhead to keep art teams productive.

Yeah exactly this. Git LFS is supposed to fix the problem, but I haven't seen it working flawlessly either yet.
Post reply on HN