Live data from Hacker News

Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

news.ycombinator.com

371–380 of 440 posts

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#371
post #43

Earlier quoted context omitted.

Even a force push doesn't destroy the reflog or runs the GC server-side. I wonder how you can accidentally loose data with Git. I've seen lot's of people not being able to find it, but really destroying it is hard.

He force pushed a diverged branch or something like that, and we only found out after a while. We were eventually able to recover because someone didn't pull. But it was not a fun experience :D

[dead]

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#372
post #354

Earlier quoted context omitted.

But that seems like pretty much the equivalent to "rm -R *"? And also just a permission/configuration issue.

To put into perspective, that was in 2014 :D There were no branch protections, and git was even harder to use. Plus everyone was new at git, obviously (we started in 2013 with mercurial, which was still a legit thing to do, and switched to git).

Yeah, these days stopping force pushes is a checkbox (default?) in GitHub.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#373
post #355

Earlier quoted context omitted.

Ah, I guess this is the curse of ignorance: I saw the sentence but didn't register its significance as I'm not familiar with what's required in game development.

[flagged]

Yeah, possibly. I have only visibility to the teams I worked with. That's partly why product market fit is hard to find, as it relies heavily on intuition. I'd be happy if I'm wrong.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#374
post #234

Out of curiosity, are there any VCSs that operate on AST instead of plaintext lines? (Or is something like this being developed or proven impossible?) I guess it should be possible to cooperate on shared codebase without need for every contributor to check in and out text files following exactly the same formatting. Or even naming convention. Or even same language, provided all collaborators can transpile to and from…

It would also alow the file structure to be relevant to source control, users could customize how the methods in a class are organised.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#375
Constructive criticism.

I would like to see much, much more in a demo. Probably around 20-30 minutes.

What was shown in the demo video was seemingly the functionality of Dropbox, shown working with one file manager and one OS.

I know it is more than that. I’ve checked your docs. You have branching models. You have cross OS support. You have a lot going on.

But that demo video really put me off. It doesn’t demonstrate anything that seems particularly useful to me, especially on the main selling point: version control. It spends most of the time showing automatic file sync, which (although not easy to do) is a basic feature of so many cloud storage platforms that it doesn’t have the wow factor these days. (It’s also a feature I find annoying and would want to disable, but it seems to be core to your approach so meh)

I know not everyone will jump immediately to the demo video to see it, but it’s what I did, and honestly… I’d scratch it and do a full intro video and put resources into doing it right.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#376
post #116

Earlier quoted context omitted.

> Don't focus too much on "git complexity" as most people already know git so it just creates an argument. I'd say this phrase is both right and wrong. It's right in the sense that it creates an argument. It's wrong in that it creates an argument with the peanut gallery of git experts. But guess what, most people using git are not experts. They're software developers who don't want to learn the intricacies of git (pr…

It is just a tough argument to make: the thing you have been using for your entire career and used almost everywhere is suddenly too complex.

I use git because other people use git, and ultimately I try to accommodate the tools that my peers are going to be used to. But I do think it's too complex (by a lot), and if I was running some kind of dictatorship I would never touch git again. Frankly, I think that git is a significantly worse tool than svn was for most use cases.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#377
post #303

Earlier quoted context omitted.

Game dev here, totally agree. File-locking across branches excited me, support for visual diffing of uassets would be insane. The platform screenshots as a git/github alternative didn't excite much interest as Plastic and Perforce are major players.

Other game devs mentioned visual diffing as well, we'll try to make this happen!

Also a game dev — if you want to attract devs, tell me why this beats P4 or Plastic. How's it similar or different? Plastic has a lot of the features you're bringing up as "new" and has great DX, which tells me your either didn't do your research, or aren't saying enough about how what you're doing is meaningfully different from them.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#378

Earlier quoted context omitted.

It is just a tough argument to make: the thing you have been using for your entire career and used almost everywhere is suddenly too complex.

I use git because other people use git, and ultimately I try to accommodate the tools that my peers are going to be used to. But I do think it's too complex (by a lot ), and if I was running some kind of dictatorship I would never touch git again. Frankly, I think that git is a significantly worse tool than svn was for most use cases.

I like git better than svn personally. But, svn is better at managing large binary files.

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#379
post #234

Out of curiosity, are there any VCSs that operate on AST instead of plaintext lines? (Or is something like this being developed or proven impossible?) I guess it should be possible to cooperate on shared codebase without need for every contributor to check in and out text files following exactly the same formatting. Or even naming convention. Or even same language, provided all collaborators can transpile to and from…

Considering many languages' very own out-of-the-box tooling (e.g. gofmt, syn) often have glaring gaps[1][2] in the understanding/roundtripping of the language's AST constructs, I would never be able to trust something like this to store and restore my code.

[1] https://github.com/golang/go/issues/20744

[2] https://github.com/dtolnay/syn/issues/782

Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

#380
post #234

Out of curiosity, are there any VCSs that operate on AST instead of plaintext lines? (Or is something like this being developed or proven impossible?) I guess it should be possible to cooperate on shared codebase without need for every contributor to check in and out text files following exactly the same formatting. Or even naming convention. Or even same language, provided all collaborators can transpile to and from…

You can do most of this in git via custom diff-driver and smudge/clean filters. For example git can already convert line-endings on the fly for windows. This is special-cased, but can just as well be implemented via smudge/clean. Oh and git-lfs is done via smudge/clean too.

One problem with that though is that smudge and clean are not used in rename detection. Git purposely skips running these filters to detect renames for performance. There are quite a lot of other issues with smudge/clean too though.
Post reply on HN