[dead]
We've raised $17M to build what comes after Git
761–770 of 785 posts
Re: We've raised $17M to build what comes after Git
#762idk what this guys can come up with, i mean anything beyond git is a bloated mess that no one wanted to use, just look at gitlab
Re: We've raised $17M to build what comes after Git
#763Earlier quoted context omitted.
I also did that with git, but it's no comparison in ergonomics. For instance, "move this hunk two commits up" is a task that makes many git users sweat. With jj it's barely something that registers as a task.
> For instance, "move this hunk two commits up" is a task that makes many git users sweat. Citation needed. You split the commit anyway you like, e.g. with the mouse or using cursor movements or by duplicating and deleting lines. Then you move it with the mouse or cursor or whatever and squash it into the other commit. Maybe some people never intend to do it, but then these probably also don't want to learn JJ. I gue…
I'm confirming the sentiment is accurate. Background: using Git (involuntarily) since 2010, did my fair share reading it's source, put honest effort into reading it's man pages, so. Jujutsu _is_ a revelation and I'm moving to it every time I'm able to: the git repository stays the same, it's the jj runs it now.
If you ever tried to have multiple WIP features merged in a Git working copy, I have a great news — with jujutsu complexity of the workflow increases linearly over the number of branches, if ever: it's almost trivial. Otherwise I very much encourage you to try — in and of itself the workflow is extremely effective, it's just Git makes it complex af.
Re: We've raised $17M to build what comes after Git
#764> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools. A bit of a strange thing to say in my book. Git isn't SVN and I think these problems are already solved with git. I agree that the interface is not always very intuitive but Git has the infrastructure which is very much fo…
This is juicero for source control.
The problem that requires a redesign is that vcs are unable to extract a subscription rent from some of the people who use git.
Re: We've raised $17M to build what comes after Git
#765building the future of source control over the incumbent tech does not bring much excitement personally.
does not takeaway the interest and funding they are able to bring. raising money is not always a bad thing, if say, there will be a webapp to go alongside their approach to workflows.
Re: We've raised $17M to build what comes after Git
#766Earlier quoted context omitted.
> 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…
> Aka you just did a strawman,
That's not what a strawman is.
> Also you answered to me in an authoritative way, when even according to you, you don’t understand my comment.
No, I didn't understand what referring to production-ready code has anything to do with making mistakes in source control.
> And also of course a nice fallacy fallacy.
You keep using words you don't understand.
> 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.
You're not actually suggesting you become immune to making mistake after a certain level of experience, are you? That would be insane.
Re: We've raised $17M to build what comes after Git
#767Earlier quoted context omitted.
Can you expand on this? How do you achieve it? Just a WIP JJ commit after every change or something more clever?
The others use `jj status`, but if I were to do this, I'd use `jj log -n0`, which has no output. All you really need is any read-only jj command. You could also turn on watchman and have this property on every save of a file and not even need to worry about hooks.
`jj util snapshot` sounds like it was meant for this.
Re: We've raised $17M to build what comes after Git
#768Earlier quoted context omitted.
The others use `jj status`, but if I were to do this, I'd use `jj log -n0`, which has no output. All you really need is any read-only jj command. You could also turn on watchman and have this property on every save of a file and not even need to worry about hooks.
`jj util snapshot` sounds like it was meant for this.
I know there was a debug command that would do it, but that was considered an unstable interface. That sounds like a better command, I’ll have to check it out, thanks!
Re: We've raised $17M to build what comes after Git
#769Earlier quoted context omitted.
The interface can be independent of the implementation. Under the hood git does everything you need. If learning to use it at a low level isnt appealing, then you can put an interface on top which is more ergonomic.
> Under the hood git does everything you need No it doesn't. Git is buggy. It also doesn't work for anything that's not a text file. It is unbelievably slow.
> Git is buggy
Citation needed on this one. Every problem I've ever seen arise with git came from someone not understanding the model or not knowing all the commands. Those don't make it better, but they don't mean it's buggy either.
Re: We've raised $17M to build what comes after Git
#770Earlier quoted context omitted.
Unsure if you want the real answer, but the financials on gitv2 will be much more appealing to a VC. Hardware is hard, slow, expensive, risky. Finally, China is the place to build physical things not the US.
What would "the financials" be on a git replacement? No one makes money on git itself. Probably not much even on the services around git, given that Microsoft funds github for its own reasons, and gitlab is constantly running out of money.
OSS as a GTM channel is well established, including amongst YC companies.
So the financial model is no different from any other SaaS. Whereas hardware is high risk capital intensive and China centric.