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

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

news.ycombinator.com

Post reply on HN
Print view View original

311–320 of 440 posts

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

#311

Post by TexasMick »

solidasparagus wrote: post #68
sasham wrote: post #5

Earlier quoted context omitted.

You're totally right, we were using BitBucket and pushing and pulling from there. It's really more of a centralized manner, but this is the usual workflow for most teams and companies and what they actually need (a single source of truth). Totally agree about backups, lesson learned :)

I want to add counter-feedback. I think focusing on git's weaknesses is really appealing. My background is more ML research and data and I viscerally connect with your pitch around both git's limited scalability and the complex/dangerous nature of git operations (ML researchers + git is not great).

Tbh they should really just learn it. It's super simple and powerful

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

#312

Post by TexasMick »

calderwoodra wrote: post #190

The world needs a git alternative. Anyone who has used mercurial at Google or Facebook knows the tooling could be much better. As soon as you have 2-3 people committing to the same repo daily, git falls apart fast. The biggest difficulties with git are merging and branch rebasing. If git could do rebases better, I would suspect software development teams to universally move about 20% faster.

2-3 people daily I would be completely surprised there's any issues.

It suggests they're working on the same files and on the same lines, why??.

My current project has 40+ developers and I haven't seen a merge conflict in a long time.

Why do you think there's issues with merging and revising, pretty much all cloud solutions have a button to do both for you.

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

#313

Post by TexasMick »

mikepurvis wrote: post #287
hasty_pudding wrote: post #222

Earlier quoted context omitted.

Rebasing is extremely easy with git. Sounds like more of a skill problem then a git problem.

I think the issue comes about more when you have refactoring going on at the same time, and suddenly multiple feature branch maintainers need to figure out if they're going to merge in the main branch, rebase onto the main branch, if it makes sense to squash their changes first before attempting either path, etc. If they get only partway through either one, it's difficult work to pause and resume, so that integration…

You can always merge feature branches together to check for conflicts

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

#314

Post by carlthome »

kristjansson wrote: post #307
foofie wrote: post #300

Earlier quoted context omitted.

> Monorepos are indeed causing problems with git, and this is one of the main arguments against them (see [1]). The article is a disappointing read. It spends a lot of time talking about monorepos and how they spell all sorts of trouble. Yet, the article makes zero mentions of submodules as a way to get the best of both worlds.

Submodules are great, but they're hardly an alternative to monorepos.

Why not? Just want to understand.

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

#315

Post by niwinz »

emgeee wrote: post #236
ta8645 wrote: post #221

There doesn't seem to be any justification offered on why it's not yet open source. Not that one is required, but it is suspicious that such a commitment isn't a priority, and that maybe there is a desire to keep closed-source as an option. Personally, I'd not want to check any assets into such a tool before it becomes open-source.

Open sourcing code can require a lot of resources to do it right (manage the community, handle licensing etc). If you don't have customers asking for it and you don't need it for customer acquisition it might not make sense.

Licensing: just choice a good safe default: apache2.0 or mpl2.0

Open sourcing does not mean you want or going to accept external contribution, just be explicit that you don't accept external contributions.

There are several open source projects that are developed with no public contribution policy. Nothing new to invent here.

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

#316

Post by kristjansson »

IshKebab wrote: post #54
guax wrote: post #36

Earlier quoted context omitted.

--force always imply data loss. You're overriding the remote state. Do people use it in an unsafe manner because they don't understand git and there lies a problem that could be tackled? yes. With that, I don't think git has any feature that is unsafe by default.

> With that, I don't think git has any feature that is unsafe by default. Well, you just mentioned `--force`. It is unsafe by default. Git has a couple of flags to make it safer (`--force-with-lease`, `--force-if-includes`) but those aren't the default.

The feature is 'git push'. --force is the opt-in to the unsafe behavior. It should not be used lightly.

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

#318

Post by xorcist »

dmazzoni wrote: post #265
sasham wrote: post #52

Earlier quoted context omitted.

Swear to god, the story is true! We were able to restore most of the work because someone didn't pull the updates. (I should have added it in the story, didn't think it was important) But it was nerve wracking :')

But if someone DID pull the update, the old commits would have still been in their local repo and they could have run "git reflog" to retrieve them.

The person, who apparently googled some command sequence and happily entered them only to find out it overwrote the team's data, could just as easily have used those google skills to search for how to undo last git operation.

Obviously this person had all the privileges required to force push the previous commit in order to save the day. The old adage of never fact-checking a good story holds true however. Not sure it's a good selling point though, by nerd sniping everyone to explain in detail what the actual problem was no one will read to the end.

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

#319

Post by osigurdson »

oblio wrote: post #239
osigurdson wrote: post #169

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.

Ummm... A lot of people just endure using git. Go to the average enterprise software shop, the ones where people don't code for fun in their spare time, and ask around. There are a lot more of those devs than unicorn and FAANG devs.

Why aren't these teams choosing something else then? If everyone on the team dislikes git, switch to mercurial or something else.
Post reply on HN