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

171–180 of 309 posts

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

#171

Post by nunez »

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…

Wholeheartedly agree.

Going from SVN to Mercurial was a night and day experience. Going from Mercurial to Git was a marginal improvement initially but a lasting change long-term.

Then there are the "visual" VCSes like Rational and TFS that are designed to _only_ work within an IDE and grokking them involves wading through hundreds of pages of corporate tech docs.

VCSes (or at least the ones I used) were generally awful before Git.

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

#172

Post by cflewis »

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?

I haven’t played with many because I simply don’t have the time between work (Google’s Piper and Git) and kids. Piper handles the monorepo by only offering files when requested by the file system at the specified commit (this is probably a gross or even incorrect simplification, but is how it presents to the user).

There are good reasons that one should keep the whole commit history to distribute a source of truth, but at the same time if one is going to place full trust in something like GitHub (as many do), there’s no reason that full trust can’t be given to a similar website that provides a Piper model with some mechanism to request more than one commit to be brought to local storage (to get more sources of truth).

End of the day, a large repo checkout is going to be limited by either your network, your CPU/storage to perform archive expansions, or frequently both. I get the impression that Android and Chromium are expanding faster than those other things are improving, but have no data to back that up.

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

#173

Post by em-bee »

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…

i mostly agree that git can do almost anything (but see the limitations others bring up), however this claim is easy to disprove:

Whatever effort you are putting into seeking or building an alternative, instead put that effort towards becoming a Git expert.

building an alternative naturally is more work than to learn git for one person, but not everyone needs to do that. a few people building an alternative could save the learning effort of many more people.

instead i'd like to point out a different reason why rebuilding git may not solve the problem:

git is good because it is powerful and flexible.

that power and flexibility by necessity makes git more complex and difficult to use.

you can build a simpler system, but then half of todays git users won't be able to use it because it won't have the features they need.

and a system that has all the features of git today and also solves the problems it currently has will be even more complex and less straigt forward to use.

the best approach is probably to have a common backend that has all the power and flexibility needed, and multiple different frontends that are simplified to only expose the features needed for a particular workflow.

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

#174

Post by chlorion »

dreamcompiler wrote: post #53
AeroNotix wrote: post #35

Earlier quoted context omitted.

Y'all know you can change the diff viewer git uses, right?

Of course. But the diffs are still line-oriented.

The diffs don't have to be line-oriented if you are using a diffing tool that isn't based on line changes.

Git itself just stores snapshots of your files, then you can bring your own diffing tool that works in any way you'd like, it's not limited to line based diffing.

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

#175

Post by syndicatedjelly »

robaato wrote: post #116
syndicatedjelly wrote: post #102

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.

Interesting, I had issues using Git LFS to store images for my personal site. I thought I just didn't know how to use it properly...

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

#176

Post by [deleted] »

lamontcg wrote: post #164
tester756 wrote: post #101

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…

The problem is that for 99.99% of the people engaged in the debate over if git is good or not and should be replaced the correct answer for them is "stop fighting it and just learn git" because there's nothing better. They need to stop thinking about how git sucks because that is literally getting in the way of their career goals and is self-sabotage. And if anyone seriously wants to try to replace git they need to u…

[deleted]

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

#178

Post by onedognight »

sroussey wrote: post #168
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…

git still has issues with lots of files. I downloaded the sec Edgar database as files and I thought it would be nice way to store and watch changes. Nope. So slow. It does not like millions of files. And all my tooling that does a “quick” git status locked up the terminal, vs code, etc.

Did you try the file system daemon (git fsmonitor--daemon start) that’s built into git that was designed to speed up git status on many files?

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

#179

Post by quickthrower2 »

nrclark wrote: post #145
zadokshi wrote: post #10

The inner workings of git are not overly complicated. The real problem is git only provides a thin layer on top of the inner workings. It’s not git that needs replacing, (it’s just saving blobs of data) it’s the user interface on top that is confusing. The problem with simplifying the user interface is that abstracting away the complexity is super difficult.

Git does have one big architectural problem IMO - native unit of storage is a blob, not a diff. Things like rebase, cherry-pick, 3-way merge, etc would be much easier in a world where the storage model was “diffs” instead of “blobs”. This would have resulted in simpler CLI tools with fewer pitfalls.

I wonder how many horrendously named and located files exist in repositories because people don’t want to fuck with the history.

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

#180

Post by [deleted] »

rendall wrote: post #119
bryanlarsen wrote: post #80

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN