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

What comes after Git

matt-rickard.com

Post reply on HN
Print view View original

31–40 of 430 posts

Re: What comes after Git

#31

Post by 5e92cb50239222b »

nine_k wrote: post #12
stellalo wrote: post #4

> I saw the pain points of git What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious

On the surface: - Git is slow on large repos, even on an SSD. - Git has trouble with large objects; git-annex and git-lfs sort of help, but are bolted on, not integral. - Git's submodules are unergonomic at best. - Git's CLI is a mess. Deeper: - Git has no idea of a conflict as a first-class object; hence merges and rebases with the user fixing the same conflicts multiple times (and `git rerere`). Compare this to Pij…

> Git is slow on large repos, even on an SSD.

Maybe on Windows, but then everything is slow on Windows. On my 2015-era machine `git pull` on the Linux kernel source tree is nearly instantaneous after the remote objects are downloaded. Same with `git status`, `git diff`, etc. I mean, that's what it was developed for, because everything else was slow.

Re: What comes after Git

#32

Post by martijnvds »

torginus wrote: post #13

My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control. You better get it right, or otherwise you get to nuke the whole repository.

Even when you rewrite the commit history, the old objects are kept for a while (or until you forcibly expire them).

You can find the "old" commits using "git reflog".

I've fixed a lot of botched rebases with that :)

Re: What comes after Git

#33

Post by oivey »

skybrian wrote: post #18
EdSchouten wrote: post #2

- A client side virtual file system (FUSE), so that you can work with large repos that exceed the size of your own system. Version control systems like Piper (Google internal) and Eden (Facebook), GitVFS (Microsoft) already do this, but adoption is marginal.

Having used Piper, I think the Go package manager's approach is better, actually, at least for a collection of packages maintained by independent teams. If you're not going to commit to fixing downstream packages for other teams when you change something, it doesn't make a lot of sense to have a monorepo. Instead, let people upgrade at their own pace.

This is a good way to put it. I think the opposite is also true: going with many repos means you are committing to other teams being on their own to upgrade. It’s difficult to know if you’ve fixed all downstream code if everything isn’t in one repo. That model makes sense for OSS. Not so sure about within companies.

Re: What comes after Git

#34

Post by dotancohen »

crmrc114 wrote: post #10
leeoniya wrote: post #3

> Semantic diff – Can we figure out how to use version control to have more context-aware merges? Can you believe that we still rely on a text diffing algorithm from 1976 (and its shortcomings)? Git still has trouble with file renaming. GitHub Copilot, but for merge conflicts? Semantic diff has been tried before, but language-specific implementations will likely never work. in case anyone missed it: https://github.co…

git mv?

Internally just rms and adds. The "Rename" feature is just a UI feature displayed when the files have identical or near-identical content.

Re: What comes after Git

#35

Post by gorgoiler »

The project management features don’t have to live inside VCS, but it would be nice to sync them there or derive some of the primitive data structures there — comment trees, approvals, CI red/green results at integration time.

A project should encapsulate the code, how we got there, what we changed, and why we changed it.

The code is your HEAD, available as a working copy. How we got there is the stack of diffs that, when applied to an empty repository, accumulate to being the current HEAD. What we changed is more nuanced that just the diffs: It’s the commit messages explaining the diffs and adding context. If the diff changes an algorithm from n^2 to n then what we changed is the runtime complexity of x, which is good for reasons y and z.

Why we changed it is the bit that’s missing. Was this work originally from a bug report? Did real-life-n stay small for our first six months and has all of a sudden become much bigger? Who was involved in deciding this was the right thing to do, what did they say, and what other approaches did we think about? Which cat meme was deemed appropriate for the final approval of the change?

Right now, that stuff is all linked to from git but it’s not really a part of the workflow unless you remain inside GitHub’s or GitLab’s ecosystems. Seeing that in the underlying tool would be really cool.

Re: What comes after Git

#36

Post by saxonww »

kadoban wrote: post #25
crmrc114 wrote: post #10

Earlier quoted context omitted.

git mv?

That's just a convenience command. Git doesn't actually record moves as anything different from a delete and an add. Many of the querying commands (eg `git log`) use heuristics to show moved files, but they end up wrong fairly often, especially if you don't mess with the parameter(s) of the heuristics.

In my experience they are correct all of the time for simple renames. It's when you move a file and make substantial edits that it gets confused.

I think it's reasonable to argue that git shouldn't get confused in this scenario, but you could also do your renames in one commit and your changes in another.

Re: What comes after Git

#37

Post by madmax108 »

I personally believe that making diffs more human friendly is the next step of evolution we need. I work with a team on a NodeJS+React project and nearly every other PR shows up as "Something changed in package.json, something changed in package-lock.json, some static assets added/modified, some JSON changed" etc and it makes reviewing code quite unwieldy (esp. since it forces folks to use Github UI interface to even see blob diffs. which is quite opinionated on when it collapses a file in the PR, and how it determines what changed in a file). I feel like git was perfect when "code" was nearly almost completely text and patches were sent over email, but there's a lot more boilerplate+blob data that goes into git today and git needs to evolve to support this.

I feel that once tools like Difftastic [1] and similar get more mainstream, and ideally more firmly entrenched within git itself, it will make code reviewing much smoother process rather than having to depend on Github or any other proprietary service.

[1] https://github.com/Wilfred/difftastic

Re: What comes after Git

#38

Post by nine_k »

5e92cb50239222b wrote: post #31
nine_k wrote: post #12

Earlier quoted context omitted.

On the surface: - Git is slow on large repos, even on an SSD. - Git has trouble with large objects; git-annex and git-lfs sort of help, but are bolted on, not integral. - Git's submodules are unergonomic at best. - Git's CLI is a mess. Deeper: - Git has no idea of a conflict as a first-class object; hence merges and rebases with the user fixing the same conflicts multiple times (and `git rerere`). Compare this to Pij…

> Git is slow on large repos, even on an SSD. Maybe on Windows, but then everything is slow on Windows. On my 2015-era machine `git pull` on the Linux kernel source tree is nearly instantaneous after the remote objects are downloaded. Same with `git status`, `git diff`, etc. I mean, that's what it was developed for, because everything else was slow.

How about `git status`?

The first SSD I bought back in 2008 was to put a large git repo on it; it helped. With much larger repos, like those I had to work with at Facebook, even an NVMe drive becomes a bit uncomfortable, and one has to use something like Watchman [1] to track changes without a rather noticeable delay.

[1]: https://github.com/facebook/watchman

Re: What comes after Git

#39

Post by mikewarot »

nine_k wrote: post #12
stellalo wrote: post #4

> I saw the pain points of git What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious

On the surface: - Git is slow on large repos, even on an SSD. - Git has trouble with large objects; git-annex and git-lfs sort of help, but are bolted on, not integral. - Git's submodules are unergonomic at best. - Git's CLI is a mess. Deeper: - Git has no idea of a conflict as a first-class object; hence merges and rebases with the user fixing the same conflicts multiple times (and `git rerere`). Compare this to Pij…

>Git is line-oriented and has no notion of semantic diffs and semantic merges. This makes it a raw tool when working with, ironically, source code.

Git is a content addressable snapshot system, with bolted on code to make it retrospectively appear to be a line-oriented system.

It's worse than you thought.

Re: What comes after Git

#40

Post by dotancohen »

gspr wrote: post #27
bergenty wrote: post #8

Earlier quoted context omitted.

I’m not qualified to go into specifics but I hate it. All version control needs to do is pull, push and branch. Version on branch is newer? You need to pull down before you can check in. Instead what we get is over complicated nonsense with commits and stashes, rebases and heads, reparenting etc. I get it you don’t want to store your code on your local machine but that’s what backups are for, that’s not what the vers…

With only push, pull and branch, how do you refer to an old version? Hence commits, or something like it, are needed. And do you seriously not see the need of rebasing? Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.

  > And do you seriously not see the need of rebasing?
Git user for a decade. I never rebase, not professionally and not in my personal projects. I merge the work of other devs, no matter how ugly their history.

I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.

Post reply on HN