this post was submitted on 02 Jul 2024
28 points (93.8% liked)

Git

2868 readers
7 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
28
A Git story: Not so fun this time | Brachiosoft Blog (blog.brachiosoft.com)
submitted 4 months ago by [email protected] to c/[email protected]
10 comments fedilink hide all child comments
top 10 comments
sorted by: hot top controversial new old
[–] [email protected] 14 points 4 months ago* (last edited 4 months ago) (2 children)

What will be the next to replace Git? Many say it might be related to AI, but no one can say for sure.

Now here is a sentence that would make me immediately stop reading the article. Thankfully it is at the end, since it was a great and interesting read.

But now I wonder, the article does mention that Git has some core design problems. Are there any new emerging VCSs that iterate on the idea and are better (or faster, or have an unique idea about how to handle stuff), or is version control basically a solved problem with Git?

[–] [email protected] 11 points 4 months ago* (last edited 4 months ago) (1 children)
  • Pijul: patch-based like Darcs but apparently solves its performance issues. In theory this improves conflict resolution.
  • Jujutsu: kind of an alternative front-end to a git repo (but not a front-end to git). Has some different ideas, like no staging area (draft commit), and some other stuff I can't remember.
  • Sapling: from Facebook. Unfortunately only part of it is available. The server is not public yet (I guess it's tired up in Facebook infrastructure too much).

And it's definitely not a solved problem. Aside from the obvious UX disaster, Git has some big issues:

  • Monorepo support is relatively poor, especially on Mac and Linux.
  • Submodule support is extremely buggy and has particularly bad UX even for Git.
  • Support for large files via LFS is tacked on and half-arsed.
  • Conflict resolution is very very dumb. I think there are third party efforts to improve this.

I think the biggest issue is dealing with very large code bases, like the code for a mid-large size company. You either go with a monorepo and deal with slowness, Windows-only optimisations and bare minimum partial checkout support.

Or you go with submodules and then you have even bigger problems. Honestly I'm not sure there's really an answer for this with Git currently.

It's not hard to imagine how this might work better. For instance if Git repos were relocatable, so trees were relative to some directory, then submodules could be added to a repo natively just by adding the commits and specifying the relative location. (Git subtree almost does this but again it's a tacked on third party solution which doesn't integrate well, like LFS.)

[–] [email protected] 2 points 4 months ago* (last edited 4 months ago) (1 children)

Aside from the obvious UX disaster, Git has some big issues:

I find this blend of claims amusing. I've been using Git for years on end, with Git LFS and rebase-heavy user flows, and for some odd reason I never managed to stumble upon these so-called "disasters". Odd.

What I do stumble upon are mild annoyances, such as having to deal with conflicts when reordering commits, or the occasional submodule hiccup because it was misused as a replacement for a package manager when it really shouldn't, but I would not call any of these "disasters". The only gripe I have with Git is the lack of a command to split a past commit into two consecutive commits (a reverse of a squash commit), specially when I accidentally bundled changes to multiple files that shouldn't have been bundled. It's nothing an interactive rebase doesn't solve, but it's multiple steps that could be one.

Can you point out what is the most disastrous disaster you can possibly conceive about Git? Just to have a clear idea where that hyperbole lies.

[–] [email protected] 0 points 3 months ago (1 children)

the occasional submodule hiccup because it was misused as a replacement for a package manager when it really shouldn’t

I don't see why using submodules as a package manager should excuse their endless bugs. I think you just have low standards.

The UX flaws of Git are very obvious IMO. Even the naming is terrible ("index"? What was wrong with "draft"?).

[–] [email protected] 1 points 3 months ago (1 children)

I don’t see why using submodules as a package manager should excuse their endless bugs.

I don't know what are these "endless bugs" you're talking about. Submodules might have a UX that's rough on the edges, but there are really no moving parts in them as they basically amount to cloning a repo and checking out a specific commit.

Do you actually have any specific, tangible issue with submodules? Even in the cases you're clearly and grossly misusing them

[–] [email protected] 1 points 3 months ago

Do you actually have any specific, tangible issue with submodules?

Yeah sure. These are few that I can remember off the top of my head. There have been more:

  • Submodules don't work reliably with worktrees. I can't remember what kind of bugs you run into but you will run into bugs if you mix them up. The official docs even warn you not to.

  • When you switch branches or pull you pretty much always have to git submodule update --init --recursive. Wouldn't it be great if git could do that for you? Turns out it can, via an option called submodule.recurse. However... if you use this you will run into a very bad bug that will seriously break your .git directory.

  • If you convert a submodule to a directory or vice versa and then switch between them git will get very confused and you'll have to do some rm -rfing.

Even in the cases you’re clearly and grossly misusing them

Oh right, so the bugs in Git are my fault. Ok whatever idiot.

[–] [email protected] 6 points 4 months ago (1 children)

It felt like the wild west for a while because there were so many open problems and each implementation seemed to be focusing on a subset of them. Git handles all of them with decent enough speed that there isn't much incentive to go against the grain.

I think Git is good enough and so ubiquitous that we won't see a competitor until coding itself drastically changes shape. Who knows what that will look like, but if it's not collections of relatively flat files then Git may someday be replaced.

[–] [email protected] 8 points 4 months ago

On the other hand, git has major issues with binary content, such as when making games. I know there is Plastic, which has some cool features, especially in regards to merging, but when Unity bought it, it got stuck in unreasonable overpriced proprietary licensing hell. Is there some kind of FOSS VCS that solves similar issues?

[–] [email protected] 1 points 4 months ago

I don't get the title. Why is it "A Git story: Not so fun this time"? What is not so fun time referring to?

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago)

Quite elaborate but also very interesting read on git and version control history.