Is Git Irreplaceable? (2019) • Hacker News Board

Re: Is Git Irreplaceable? (2019)

#531

Post by P_I_Staker » Wed, Jan 08, 2020, 9:35 PM UTC

mikl wrote: post #229

comex wrote: post #48

Git's biggest flaw is that it doesn't scale. If a new system can fix that without sacrificing any of Git's benefits, I think it can topple Git. It's ironic that Git was popularized in the same era as monorepos, yet Git is a poor fit for monorepos. There have been some attempts to work around this. Google's `repo` command is a wrapper around Git that treats a set of smaller repos like one big one, but it's a (very) le…

Git scales well enough for almost everyone (especially if you have a little discipline with what you put in the repo). It’s only huge megacorps that need larger scale things like GVFS. As for large files, that is not what Git is for. Git is for source code . Much like how you don’t put large files in your RDBMS, you should not be putting them in your SCM either.

Honestly, you can use Git for large files with lfs. I wouldn't say I love this approach, but it isn't that bad now. You do have to make room for yet-another-tool, and you now have centralized version control comingling with your distributed tool (essentially making it central); but you can still use everything you love about git, and if your lfs doesn't change, you don't need to be connected to a server. It certainly feels pretty absurd. This isn't even a problem in SVN, but now we're tacking on another tool that you have to learn, and introduces issues.

Re: Is Git Irreplaceable? (2019)

#532

Post by P_I_Staker » Wed, Jan 08, 2020, 9:36 PM UTC

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.

Yup, doesn't sound like a negative to me. People will still try to build simpler ecosystems like GitLab/GitHub/Atlassian, with similarly mixed results.

Re: Is Git Irreplaceable? (2019)

#533

Post by P_I_Staker » Wed, Jan 08, 2020, 9:40 PM UTC

tomesch1982 wrote: post #237

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.

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.

Disagree. I could teach a child to use git. I don't agree it's elegant in a face value way. Yet if you've used other version control systems, git has features that you'd dream of (I "invented" some of the features of git on my own). So in a way it really is an elegant solution. I can't think of much that I really hate, or wish to change; and I can't think of any serious proposal to "fix" it.

Re: Is Git Irreplaceable? (2019)

#534

Post by P_I_Staker » Wed, Jan 08, 2020, 9:41 PM UTC

chiefalchemist wrote: post #306

baud147258 wrote: post #294

Earlier quoted context omitted.

If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. And personally I prefer a VCS with less ways to shoot myself in the foot than git.

Agreed. If the applications we built using git were as awkward as git...our users and clients would scream, or worse.

I don't understand the relevance of git in all of that

Re: Is Git Irreplaceable? (2019)

#535

Post by P_I_Staker » Wed, Jan 08, 2020, 9:45 PM UTC

munmaek wrote: post #406

baud147258 wrote: post #294

Earlier quoted context omitted.

If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. And personally I prefer a VCS with less ways to shoot myself in the foot than git.

You can almost always recover from your mistakes with git reflog.

Yes and no. I'm a git guy and a fan, but you can really, really mess things up. Usually, this is only when using features like force push; however, there are arguably legitimate use cases for that.

Buddy had a teammate that almost force pushed references from a slightly different repo. What a mess that could have been! I agree regarding the usefulness of reflog, and think the complaints about messing things up with rebase, reset, ect are overblown. It really isn't an issue for intermediate users.

Re: Is Git Irreplaceable? (2019)

#536

Post by ben509 » Wed, Jan 08, 2020, 10:01 PM UTC

wyoung2 wrote: post #438

ben509 wrote: post #429

Earlier quoted context omitted.

I'd rather lock files, but be able to unlock them, to be able to coordinate with others and proactively reduce merge conflicts.

The only way to make that simple is to centralize the version control system so that you can have a single arbiter of who has what locked. To add easy locking to Git, you'd have to turn it back into a non-distributed VCS. I don't think I need to sell the value of DVCS over VCS, but what seems to get lost is that buys you a certain amount of essential complexity, expressed in the CAP theorem and its consequences. We d…

I'm talking about purely advisory locks. Accessing a locked file would let you know who locked it, and if you unlock it, it would just notify them. So it's just a communications mechanism in addition to regular merges.

The alternate method is that locking a file marks you as an interested party to a merge, allowing you to review the correctness of a merge.

This would be purely to avoid changes being lost during merges.

Re: Is Git Irreplaceable? (2019)

#537

Post by ric2b » Wed, Jan 08, 2020, 10:43 PM UTC

comex wrote: post #197

yaih wrote: post #150

Earlier quoted context omitted.

"Barney Oliver was a good man. He wrote a letter one time to the IEEE. At that time the official shelf space at Bell Labs was so much and the height of the IEEE Proceedings at that time was larger; and since you couldn't change the size of the official shelf space he wrote this letter to the IEEE Publication person saying, since so many IEEE members were at Bell Labs and since the official space was so high the journ…

What is the analogy here? The first guess that came to my mind was the monorepo versus multi-repo debate: since Git can only support repos that are so large (shelf space) without getting slow, you should split up your repos (journal size) even if semantically you would prefer a monorepo. But that would support the point I was making, whereas the obliqueness of your reply makes me think you probably meant to criticize…

I think he's comparing the journal to the tool (harder to change, impacts everyone) and the shelf to the problem that only impacts a few organizations but actually a lot of people because those organizations are so large.

Re: Is Git Irreplaceable? (2019)

#538

Post by Nullabillity » Wed, Jan 08, 2020, 11:32 PM UTC

MaulingMonkey wrote: post #505

chrisweekly wrote: post #328

Earlier quoted context omitted.

"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 s…

I can sympathize with the game assets argument, but this problem is just the result of trying to stuff a square peg into the round hole.

Build artifact caching is a different problem from source control, with very different requirements:

1. As you mentioned, the artifacts tend to get huge.

2. The cache needs to be easy to bypass. From your example, it needs to be easy for the C++ engine devs to do builds like "the game but with the new engine" to test out their changes.

3. The cache needs to be precise, so you don't end up with mystery errors once it finally does trigger, or people wondering why their changes don't seem to apply.

4. The builds need to be exactly reproducible, so you don't end up with some critical package that only Steve Who Left 5 Years Ago could build (or Jenkins Node 3 That Just Suffered A Critical HDD Failure).

Git either doesn't care about or fails spectacularly for each of those points. In particular, #3 will be very confusing since there will be a delay between the code push and the related build push.

Nix[0] solves #2 and #3 by caching build artifacts (both locally and remotely[1][2][3]) based on code hashes and a dependency DAG (for each subproject or build artifact, so changing subproject X won't trigger a rebuild of unrelated subproject Y, but will rebuild Z that depends on X). It helps with #4 by performing all builds in an isolated sandbox.

#1 is solved by evicting old artifacts, which is safe as long as you trust #4. If the old artifact is needed again then it will be rebuilt for you transparently. Currently this is done by evicting the oldest artifacts first, but it could be an interesting project to add a cost/benefit bias here (how long did it take to build this artifact, vs the amount of space it consumes?).

[0]: https://builtwithnix.org/

[1]: https://nixos.wiki/wiki/Binary_Cache

[2]: https://nixos.org/nix/manual/#sec-sharing-packages

[3]: https://cachix.org/

Re: Is Git Irreplaceable? (2019)

#539

Post by munmaek » Thu, Jan 09, 2020, 12:06 AM UTC

P_I_Staker wrote: post #535

munmaek wrote: post #406

Earlier quoted context omitted.

You can almost always recover from your mistakes with git reflog.

Yes and no. I'm a git guy and a fan, but you can really, really mess things up. Usually, this is only when using features like force push; however, there are arguably legitimate use cases for that. Buddy had a teammate that almost force pushed references from a slightly different repo. What a mess that could have been! I agree regarding the usefulness of reflog, and think the complaints about messing things up with r…

Hence almost always. It’s not a common situation to delete commits from history, etc.

I don’t see the capability to force push as a negative. There are situations in which it’s necessary, like forcibly removing history (something I had to do just today).

Git gives you the ability to shoot yourself in the foot, so it’s up to the operator to not make a mistake like that without backing up the repo to a different place first, etc. Something something only a poor carpenter blames their tools.

Re: Is Git Irreplaceable? (2019)

#540

Post by roca » Thu, Jan 09, 2020, 12:42 AM UTC

hinkley wrote: post #481

roca wrote: post #247

Earlier quoted context omitted.

Only if those people never have to learn git in those five years. Maybe in some niches they wouldn't have to, but lots would.

So you think git will be different from SVN when a new contender comes along?

Yes. I've been programming for nearly 40 years and I only had to use Subversion a couple of times; I never really learned it. OTOH I have to use git for all kinds of projects. Learning git is essential in a way that SVN never was.

I think part of the reason is that SVN never took over from CVS as completely as git took over from everything else. I think another part of the reason is that the number, size and scope of open-source projects exploded since git and Github appeared, and they mostly chose git.

Also relevant: the only project that I recently interacted with that was using SVN is LLVM, and it was faster/easier to use the Github mirror than to use SVN.