Live data from Hacker News

We've raised $17M to build what comes after Git

blog.gitbutler.com

741–750 of 785 posts

Re: We've raised $17M to build what comes after Git

#741

Earlier quoted context omitted.

I've considered trying to get Linus to be the knowledgeable person given his history. I haven't actually reached out though. I badly want someone to take that deep dive given the work I've put in to be ready for it

Now you understand why people have non technical co founders!

I have a co-founder who is half-technical, and without his help and support I would not have been able to keep going on this project.

By the way it finally occurred to me who I should ask to do the deep dive: Gary Bernhardt

Re: We've raised $17M to build what comes after Git

#742
> I know what you’re thinking. You’re hoping that we’ll use phrases such as “we’re excited,” “this is just the beginning,” and “AI is changing everything”. While all those things are true, I’ll try to avoid them and instead make this announcement a little more personal.

Refreshing. I am so tired of the usual PR-approved phrases that you read in every announcement.

Other than that, I agree with other comments: not sure what Git's problem is, and what they are supposed to solve. Star Wars' "it's a trap" vibes.

Re: We've raised $17M to build what comes after Git

#743

Earlier quoted context omitted.

If I remember correctly, jj is one guy who works at Google. Which presents a separate worry, which is that one day, when jj gets popular enough, Google will consume it, make it shit, change the name of it every six months and then shut it down.

That hasn't really been the case for a while imo: Martin works at Google and is paid to work on jj (there are also other Google employees who contribute, not sure whether they're paid to). jj is in use (wide use? No idea) alongside Google's internal tool (piper) with which it can interact (and with which it has some features in common) because jj has a pluggable backend architecture. While I hate to engage in specula…

[dead]

Re: We've raised $17M to build what comes after Git

#744

Earlier quoted context omitted.

Why would users who never wanted change proactively switch to your product in the first place? And putting them aside, you haven't listed a single concrete technical idea that would indicate you have the vision for a car. Maybe you should spend more time on that than drumming up your grift-adjacent persecution complex.

They wouldn't. Every adoption curve needs early adopters, who will be people not satisfied with the current state of things. But obviously most people aren't early adopters. If you would like me to list a single concrete technical idea, I am pleased to oblige. The idea is: universal gaps. Our syntactic-semantic documents can have holes in them, places where we know some content is missing. That allows a document to b…

That idea has nothing to do with source control that would replace git. It also already exists in the form of TODO tags and is handled exactly as you describe in JetBrains IDEs[0] (plus helpful semantic highlighting), and probably others as well.

[0] https://www.jetbrains.com/help/idea/using-todo.html

Re: We've raised $17M to build what comes after Git

#745

Earlier quoted context omitted.

They wouldn't. Every adoption curve needs early adopters, who will be people not satisfied with the current state of things. But obviously most people aren't early adopters. If you would like me to list a single concrete technical idea, I am pleased to oblige. The idea is: universal gaps. Our syntactic-semantic documents can have holes in them, places where we know some content is missing. That allows a document to b…

That idea has nothing to do with source control that would replace git. It also already exists in the form of TODO tags and is handled exactly as you describe in JetBrains IDEs[0] (plus helpful semantic highlighting), and probably others as well. [0] https://www.jetbrains.com/help/idea/using-todo.html

I'm talking about a universal placeholder, something that you're free to use anywhere, in any language, for any part of a syntax tree that is missing.

A TODO comment can't do that because the syntax conflicts. For a regex the conflict would look like `//* TODO *//`, and for a comment it would look like `// /* TODO */`. Both have an existing meaning, and in neither case is that the meaning I want.

If I could have a magic "stuff goes here" character this would be solved. I often use · to represent the idea of this magic character. That gives you /·/ and //· at least, but of course it isn't safe to assume that no language will ever assign meaning to the · character so we can't literally use it as the universal gap. To get something universal, you need to move from using a sentinel token to using embedded/encoded data.

Re: We've raised $17M to build what comes after Git

#746

Earlier quoted context omitted.

That idea has nothing to do with source control that would replace git. It also already exists in the form of TODO tags and is handled exactly as you describe in JetBrains IDEs[0] (plus helpful semantic highlighting), and probably others as well. [0] https://www.jetbrains.com/help/idea/using-todo.html

I'm talking about a universal placeholder, something that you're free to use anywhere, in any language, for any part of a syntax tree that is missing. A TODO comment can't do that because the syntax conflicts. For a regex the conflict would look like `//* TODO *//`, and for a comment it would look like `// /* TODO */`. Both have an existing meaning, and in neither case is that the meaning I want. If I could have a ma…

JetBrains supports TODOs in every language I use/am aware of.

Your syntax assertion doesn't make sense. Commented code is supported without interference in every common language I'm aware of.

> I often use · to represent the idea of this magic character

You can configure JetBrains to treat that character the same as a TODO.

(Not sure why I'm replying to what is probably AI-generated nonsense rambling, but hope that's helpful in case you're being earnest.)

Re: We've raised $17M to build what comes after Git

#747
post #669

Earlier quoted context omitted.

> Did you ever accidentally commit something that contains a secret that can't be in the repository? What do I need to do on top of a git force push, and some well documented remote reflog/gc cleanup, which I can’t find with a single search/LLM request? Are we there, where we don’t have enough developers who can do this without feeling it as a burden? Or are we there where this level of basic logic is not needed to i…

> What do I need to do on top of a git force push, and some well documented remote reflog/gc cleanup, which I can’t find with a single search/LLM request? This is a self-defeating argument. You're essentially saying we shouldn't improve something because it can be done with a handful of commands (you already know btw) and prompting an LLM. > Are we there, where we don’t have enough developers who can do this without…

No, I’m saying that you can do this without replacing git. You can make it simpler even without replacing git. Aka you just did a strawman, if you are really into these. Also you answered to me in an authoritative way, when even according to you, you don’t understand my comment. You can figure out a logical fallacy name for this. And also of course a nice fallacy fallacy.

Btw, I’m also saying that who cannot find how it can be solved right now with git, those shouldn’t be allowed anywhere near a repo with write permission, no matter whether you use git or not. At least until now, this level of minimal logical skill was a requirement to be able to code. And btw regardless the tool, the flow will be the exact same: ask a search engine or ml model, and run those. The flow is like this for decades at this point. So those minimal logical skills will be needed anyway.

The problem mainly is that when they don’t even know that they shouldn’t push secrets. You won’t be able to help this either any tooling. At least not on git level.

Re: We've raised $17M to build what comes after Git

#749
post #572

Earlier quoted context omitted.

Every success story and happy conversion to jj is evidence that hg should have won the DVCS war, but more importantly, that VCSes and their inherent merits and tradeoffs were always secondary to the social networks underpinning them. GitHub as a defacto monopoly really killed innovation in the VCS space, but also shifted the focus and attention elsewhere. That's why I don't think there'll be so much of a "post-git" w…

LOL. In 2007, I did a side-by-side comparison of SVN, Mercurial and git with my codebase at work (~700k LOC). I know hg got faster eventually, but I still can't believe people say "hg should have won the DVCS war" with a straight face. It was orders of magnitude slower in my tests. Like, 20 minutes to commit large xml files (yeah, I know, but that's where we were). Not just a few ms slower, unbearably slow for severa…

This isn't an apology or a deflection, but different VCSes strike different trade-offs in terms of speed per workload. The mercurial storage model is comparable to video encoding in that it has a somewhat equivalent of "key frames" and alternates differential and full revisions¹. This makes workloads like bisecting or jumping to long-distance commits more efficient, at the expense of the time to create new commits.

For your use-case, mercurial has had a `largefiles`² extension for a very long time (long before git-lfs).

> I liked its features better, but chose git, and that was the correct decision.

Anyhow, my personal story with git is that I bought into the hype and social effects without really challenging my assumptions ("it must be the best, everyone says so"), until I got very fed-up with its obnoxious UI, and someone on IRC told me "ehh, give hg a shot". Nowadays, I mostly interact with git repos through hg-git and jj.

¹: https://www.kernel.org/doc/ols/2006/ols2006v2-pages-91-98.pd...

²: https://wiki.mercurial-scm.org/LargefilesExtension

Re: We've raised $17M to build what comes after Git

#750

Earlier quoted context omitted.

> To me it's not clear what the problem is that would require a redesign. The interface is still bad. Teaching people to use git is still obnoxious because it's arcane . It's like 1e AD&D. It does everything it might need to, but it feels like every aspect of it is bespoke. It's also relatively difficult to make certain corrections. Did you ever accidentally commit something that contains a secret that can't be in th…

git rebase -i git push origin mainline -f

git log --all --reflog -- path/to/secret-file
Post reply on HN