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

Is Git Irreplaceable? (2019)

fossil-scm.org

Post reply on HN
Print view View original

271–280 of 559 posts

Re: Is Git Irreplaceable? (2019)

#271

Post by MaulingMonkey »

taftster wrote: post #188
Ace17 wrote: post #158

Earlier quoted context omitted.

I work for a 40-people game studio. A major limitation of git is how it deals with many "big" (~10Mb) binary files (3D models, textures, sounds, etc.). We ended up developing our own layer over git, and we're very happy ; even git-lfs can't provide similar benefits. This technique seems to be commonplace for game studios (e.g Naughty Dog, Bungee), so certainly git has room for improvement here.

Do you have tools that you can utilize diffs from your binary file changes? Or does a change simply just replace all the bytes. I'd argue if it's the later, that git was never the right choice to begin with. You don't really want to record a full 10MB of data every time you change one pixel in your texture or one blip in your sound, right? So I don't know if this is a "major limitation" of git per se. Not saying ther…

While I can't speak for the person you're replying to, the technology at least exists. Binary diffs are sometimes used to distribute game updates, where you're saving on bandwidth for thousands if not millions of players - which costs enough $$$ to actually be worth optimizing for. On the other hand, between simpler designs and content encryption being sometimes at odds with content compression... so is just sending the full 10MB. For a VCS - I'd probably be happy enough to just have storage compression - using any of the standard tools on the combination.

> You don't really want to record a full 10MB of data every time you change one pixel in your texture or one blip in your sound, right?

Actual changes to content in a gamedev studio are very unlikely to be as small as a single pixel. Changes to source code are unlikely to be as small as a single character either. And we definitely want a record of that 10MB.

We're willing to sacrifice some of our CI build history. Maybe only keeping ~weekly archives, or milestone/QAed builds after awhile, of dozens or hundreds of GB - and maybe eventually getting rid of some of the really old ones eventually. Having an exact binary copy of a build a bug was reported against can be incredibly useful.

Re: Is Git Irreplaceable? (2019)

#272

Post by bhaak »

hn_acc_1 wrote: post #38
ken wrote: post #19

Every version control system that's become dominant in my lifetime became popular because it fixed a major obvious flaw in the previous dominant system (RCS, CVS, SVN). From where I sit, Git has a couple obvious flaws, and I expect its successor will be the one that fixes one of them. The most obvious (and probably easiest) is the monorepo/polyrepo dichotomy.

I don't see any obvious flaws with Git. The monorepo/polyrepo discussion exists apart from your choice of version control system and has little to do with Git, as far as I can tell

How about history tracking for file renames doesn't work well? It's hit and miss if git blame --follow works.

Subversion did this better even before Git existed.

Git is completely oblivious to moving code from one file to another. Git blame will never show you the original commit if you just relocated a method to another file. Due to this, refactoring often put additional hurdles into exploring the code history.

Re: Is Git Irreplaceable? (2019)

#273

Post by mcv »

ehnto wrote: post #245
tomesch1982 wrote: post #237

Earlier quoted context omitted.

Git is neither easy not is it really elegant. It is useful for projects like Linux™ but for the vast majority of projects way better tools like mercurial or fossil would be a much better fit.

It's been immensely useful in every software project I have ever partaken in. None of them were like linux.

It is immensely useful. That doesn't mean that some other tool might not be better for most cases.

I love git, and don't know most other post-SVN version control systems, but I do recognise the complaints people have about git. There's clearly still room for improvement.

Re: Is Git Irreplaceable? (2019)

#274

Post by j88439h84 »

Ace17 wrote: post #158
kemitche wrote: post #120

Earlier quoted context omitted.

I disagree that Git's biggest flaw is its lack of scalability. Cases where git needs to scale tend to be isolated to companies that have the manpower to build a finely-tuned replacement (see: MS, Google). Git's flaws are primarily in usability/UX. But I think for its purpose, functionality is far more important than a perfect UX. I'm perfectly happy knowing I might have to Google how to do something in Git as long as…

I work for a 40-people game studio. A major limitation of git is how it deals with many "big" (~10Mb) binary files (3D models, textures, sounds, etc.). We ended up developing our own layer over git, and we're very happy ; even git-lfs can't provide similar benefits. This technique seems to be commonplace for game studios (e.g Naughty Dog, Bungee), so certainly git has room for improvement here.

What does your layer do?

Re: Is Git Irreplaceable? (2019)

#275

Post by muxator »

reissbaker wrote: post #186
kccqzy wrote: post #152

Earlier quoted context omitted.

Mercurial is probably that competitor. Only slightly slower than Git. Works on very large monorepos (as large as Facebook's or Google's monorepo). Very similar workflow as compared to Git, with some minor differences in terminology.

As an FB employee, I use hg regularly (because it is required). I would not use it as a git replacement for non-FB-sized repos. It has some weird design choices (e.g. branching is bad), and it very often requires manual intervention for merges that git performs correctly and automatically. You can get around branching-is-bad by changing your workflows a bit, but you can't get around the bad merges: over time it's lik…

You can always strip a bad committed merge, abort a bad uncommitted one, and perform it again (maybe with different tooling).

Normally mercurial stops when there are conflicts it cannot resolve reliably. In that cases, have a try at kdiff3: it handles hairy merges quite well. In a lot of cases even automatically (and correctly).

There is always meld, but I'd say kdiff3 is superior wrt merge conflict resolution.

Re: Is Git Irreplaceable? (2019)

#276

Post by tyingq »

MaulingMonkey wrote: post #271
taftster wrote: post #188

Earlier quoted context omitted.

Do you have tools that you can utilize diffs from your binary file changes? Or does a change simply just replace all the bytes. I'd argue if it's the later, that git was never the right choice to begin with. You don't really want to record a full 10MB of data every time you change one pixel in your texture or one blip in your sound, right? So I don't know if this is a "major limitation" of git per se. Not saying ther…

While I can't speak for the person you're replying to, the technology at least exists. Binary diffs are sometimes used to distribute game updates, where you're saving on bandwidth for thousands if not millions of players - which costs enough $$$ to actually be worth optimizing for. On the other hand, between simpler designs and content encryption being sometimes at odds with content compression ... so is just sending…

I usually see bsdiff or courgette cited as good tools for binary diffs:

http://www.daemonology.net/bsdiff/

https://www.chromium.org/developers/design-documents/softwar...

Re: Is Git Irreplaceable? (2019)

#277

Post by cesarb »

hinkley wrote: post #147
jayd16 wrote: post #89

Earlier quoted context omitted.

>I don't see any obvious flaws with Git. Large files and long histories hinder its total dominance in the game and art industries. Because of git's shortcomings polyrepo is a near necessity not simply a stylistic choice. LFS is a bolt on solution that could/should have better support.

Git stores the diffs in chronological order doesn’t it? I recall reading about someone doing a commercial implementation where the commits are stored in reverse chronological order. I’d been thinking that was github but I’ve never been able to find the article again.

Git's model (which it copied from monotone IIRC) is not diff-based, it's snapshot-based. That is, commits are not stored as a diff to the previous commit, but as the whole state of the tree plus a pointer to the previous commit(s).

As an optimization, when it packs several objects together in a pack file, it can store objects as a delta to other (possibly unrelated) objects; there's a whole set of heuristics used to choose which objects to delta against, like having the same file name. And yes, one of these heuristics does have an effect similar to "reverse chronological order"; see https://github.com/git/git/blob/master/Documentation/technic... for the details.

Re: Is Git Irreplaceable? (2019)

#278

Post by mcv »

tomesch1982 wrote: post #265
peteretep wrote: post #249

Earlier quoted context omitted.

> way better tools I work with a group of people who all know enough git that we're productive, and a few of us know enough git to solve complicated problem. I've not seriously considered fossil or mercurial -- what are the top three tangible benefits I'd get from them getting our team to switch?

That is exactly the point. For git you need the ecosystem to cope with it's shortcomings and in addition some experts to help you out of the pickles this software gets you into. I mainly use fossil for personal projects. Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management. The setup is ridiculously…

I hadn't heard of fossil yet, but I'll definitely look into it.

Re: Is Git Irreplaceable? (2019)

#279

Post by saurik »

alkonaut wrote: post #228
tasuki wrote: post #199

> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.

I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. For example a typical question on Stackoverflow is "How do I answer which branch this branch was created from", always has 10 smug answers saying "You can't because git doesn't really track that, bran…

Another simple tracking thing that git doesn't do that would easily make git much much better is if it tracked when you did a cherrypick of another commit in the commit graph (not just as some kind of metadata comment in the commit message, but as a kind of soft parent); then if you did a rebase, you could actually "reverse engineer" the rebase (if and only if you absolutely needed to, such as to track what happened during a squash, or to automate re-applying the rebase correctly to someone who was tracking one of the prior commits) and it would largely solve the question of "merge or rebase" with "por que no los dos".

Re: Is Git Irreplaceable? (2019)

#280

Post by mcv »

rimliu wrote: post #259
matsemann wrote: post #216

Earlier quoted context omitted.

People have probably been happy with their tools for centuries. Just because one cannot imagine something better doesn't mean there's no possibility for it to exist. If anything, this defeatist attitude may prove the author right.

I remember what was the go-to tool before git. It was Subversion. And CVS before that. I would not say people were happy with those tools.

I was happy with SVN because I used CVS before. I was even happy with CVS, because I had nothing before. It's hard to imagine now.

Software development has seen massive improvements in the past 20 years. I see no reason why that would stop now.

Post reply on HN