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

501–510 of 559 posts

Re: Is Git Irreplaceable? (2019)

#501

Post by wyoung2 »

alkonaut wrote: post #498
wyoung2 wrote: post #486

Earlier quoted context omitted.

> I’d guess not one user in 100.000 uses git decentralized I understand your sentiment, but the denominator in that fraction is probably much lower than your guess. Consider even simple cases like the disconnected laptop case. You may work at a small office with only local employees, and so you have one central "blessed" repo, but if one person locks a file and then goes off to lunch, working on the file while at the…

Not sure I understand the problem. If I lock fileX and go to lunch, then I own the lock on that file while I’m out to lunch. It’s basically analogous me pushing the file fileX.lock to the repo next to fileX, with my user id as content. I can only do it if it isn’t there. Everyone else will only see that lock if they fetch and if they don’t, they might edit their local copy of fileX too, but would be prevented from pu…

> Not sure I understand the problem. If I lock fileX and go to lunch, then I own the lock on that file while I’m out to lunch.

And if you go on vacation for two weeks instead?

Re: Is Git Irreplaceable? (2019)

#502

Post by wyoung2 »

jnurmine wrote: post #499
wyoung2 wrote: post #479

Earlier quoted context omitted.

> By the way, the "one checkout per repository" is not strictly true. You must be referring to just the table at the top, not to the detailed argument below, which mentions git-worktree and then points you to a web search that gives a bunch of blog articles, Q&A posts, project issue reports and such talking about the problems that come from using that feature of Git. I suspect this is because git-worktree is a relati…

> You must be referring to just the table at the top, not to the detailed argument below Well, not entirely, because in my opinion the detailed argument kind of hand-waves away the entire git worktree. Continuously switching branches inside a single large Git repo is certainly a suboptimal way to work with Git, but most of the time one should be able to avoid that with the worktree (though the worktree stuff is, of c…

You’re not addressing the list of problems resulting from the use of this tacked-on feature.

Also, Git continues to be taught with the switch-in-place method by default.

I’m not saying it is impossible to get a Fossil-like workflow with Git, just that there are consequences from that not being the default.

Re: Is Git Irreplaceable? (2019)

#503

Post by taftster »

smcameron wrote: post #377
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…

> 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? Ideally, yes, why wouldn't I? I want to capture the exact state of the thing at each change.

I kind of phrased that poorly. I should have added the context of "in git". Saving a new 10MB file every time you change it, as per my original premise, is not something that git was really designed for. It's asking a screwdriver to do the work of a hammer.

I totally get the use case of saving each iteration of that 10MB file _somewhere_. But expecting git to do that job is not the right level of expectation, was my main point.

When I have worked with binaries like that described, I will place a URI reference to a file hash and have something that knows how to resolve it. A file store (think S3 or whatever) that has files named: texture1.dat-[sha1] and change the reference to the file in the source. e.g. a "poor man's" version control by way of file naming conventions. Does this approach work in your world?

Re: Is Git Irreplaceable? (2019)

#504

Post by vvillena »

Ntrails wrote: post #492
vvillena wrote: post #355

Earlier quoted context omitted.

> Usually I accidentally committed to local master and then did a couple other things Create a new branch and check it out while you are on the last commit (git checkout -b my-branch), delete the master branch (git branch -D master), and pull it again (git pull -u origin master). You'll end up with a local branch with a bunch of commits that you can merge, rebase or cherrypick, depending on what you want. If you want…

Deleting master is a thing that would _actually_ never have occurred to me! A neat trick That being an example that I remember from late last year, there are just sharp edges to git I end up catching myself on :)

The git "master" branch is just an example of 'convention over configuration': some commands use it as the default argument, just like "origin" is the default remote name. Nothing in git is special or sacred! :)

Re: Is Git Irreplaceable? (2019)

#505

Post by MaulingMonkey »

chrisweekly wrote: post #328
MaulingMonkey wrote: post #271

Earlier quoted context omitted.

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…

"Having an exact binary copy of a build a bug was reported against can be incredibly useful." Sure, immutable build artifacts can be invaluable -- but aren't they also an orthogonal concern?

> Sure, immutable build artifacts can be invaluable -- but aren't they also an orthogonal concern?

One person's immutable build artifact is another person's vendored build input.

It's common to vendor third party libraries by uploading their immutable build artifacts (.dll, .so, .a, .lib, etc.) into your VCS, handling distribution, and keeping track of which versions were used for any given build. It makes a lot of sense if those third party libraries are slow to build, rarely modified, and/or closed source - no sense wasting dev time forcing them to rebuild it all from scratch.

The next logical step is to have a build server auto-upload said immutable build artifacts into your VCS, for those third party libraries that you do have source code for, when your VCS copy of said source is modified. Much more secure and reproducable than having random devs do it.

And hey, if your build servers are already uploading build artifacts to VCS for third party libraries, why not do so for your own first party build artifacts too? Tools devs spending most of their time in C# probably don't need to spend hours rebuilding the accompanying C++ engine it interoperates with from scratch, for example, so why not "vendor" the engine to improve their iteration times?

This can lead to dozens of gigs of mostly identical immutable build artifacts reuploaded into your VCS several times per day, with QA testing and then integrating those build artifacts into other branches on top of that. The occasional 10MB png is no longer noticable by comparison.

Re: Is Git Irreplaceable? (2019)

#506

Post by lmm »

bhaak wrote: post #287
lmm wrote: post #112

Earlier quoted context omitted.

Disagree. SVN was always a pain. Committing is really slow and merging is bad (particularly for things like directory renames).

If all you had before was CVS then SVN wasn't a pain. Atomic commits and file renames.

SVN had improvements over CVS, but it still had obvious pain points. So there was still an obvious opportunity for a better VCS to come along.

Re: Is Git Irreplaceable? (2019)

#507

Post by kccqzy »

brachi wrote: post #342
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.

> Only slightly slower than Git That's interesting. In your examples isn't it fast because monorepos are network-based, as in, you only fetch what you need when you need it? Also reminded me of discussions around CPython's startup time and how one use case where milliseconds matter is in small cli utilities such as Mercurial.

What I mean is daily operations on the repo like viewing a diff, committing, amending, checking out a different commit, etc. Without doing precise measurements, I would tend to think that it's mostly caused by the slowness of CPython, as compared to a C executable (Git).

The entire repo is stored on a networked file system. So essentially every file operation is remote. That doesn't actually contribute to much slowness because when I didn't use hg, operations were noticeably faster.

Re: Is Git Irreplaceable? (2019)

#508

Post by bhaak »

lmm wrote: post #506
bhaak wrote: post #287

Earlier quoted context omitted.

If all you had before was CVS then SVN wasn't a pain. Atomic commits and file renames.

SVN had improvements over CVS, but it still had obvious pain points. So there was still an obvious opportunity for a better VCS to come along.

Sure but you could say the same about Git.

With time, the standard requirements rise and we get more demanding.

How about a VCS that not only diffs line by line but saves the diffs as editing delta?

Or that understands the syntax of the code and can differentiate a variable renaming from an actual code change?

Or connecting different repositories is hardly solved with Git. Submodules suck, grafting even more so. Or you can't make one repository out of two and keep their Git history intact.

Re: Is Git Irreplaceable? (2019)

#509

Post by sigjuice »

adrianmsmith wrote: post #211
tenken wrote: post #109

Earlier quoted context omitted.

Do you work on a team? Or in a job were you need to have an audit trail for your work? Commit messaged and many other features of Git like branching and tags are indespensible for sharing and collaborating on code.

Bit Git isn't great for audit trails given that you can go back and alter previous commits, in contrast to pretty much any other VCS, including Subversion and Fossil. (I know, technically, altering commits creates new commits in Git, but it comes to the same thing.)

Are there any documented cases of mainstream projects that have rewritten their history?

Re: Is Git Irreplaceable? (2019)

#510

Post by 1auralynn »

erikbye wrote: post #292
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.

Why did you not use Plastic SCM or Perforce?

I can't recommend Plastic enough - it's so fast and a great UI but super powerful. I've been using it at my company for years.
Post reply on HN