4 ms·

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 c

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.

hasty_pudding 3y ago
Rebasing is extremely easy with git. Sounds like more of a skill problem then a git problem.
- mikepurvis 3y ago
  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 work is fundamentally hard to collaborate on or even really review. And never mind maintaining an ongoing integration of multiple unmerged feature branches— perhaps that's more of a "front end" issue for GitLab and Github to solve, but the whole business of patchsets and the like is very much unsolved, and that's painfully obvious when you see Debian storing their quilt patches inside of of a git repo, rather than being able to leverage git's native capabilities to achieve those effects: https://salsa.debian.org/debian/netplan.io/-/tree/debian/0.105-3/debian/patches https://salsa.debian.org/debian/netplan.io/-/tree/debian/0.1...
  - TexasMick 3y ago
    You can always merge feature branches together to check for conflicts
dclowd9901 3y ago
I don’t understand how it isn’t easy? “git merge origin/master” Done. Unless you have a conflict, then fix it and commit. It couldn’t be simpler. If there’s value in this product, it won’t be because it’s somehow simpler than git.
withinboredom 3y ago
rerere has worked pretty well for me when handling conflicts and it’s built into git. I’ve worked with hundreds of engineers in a single codebase. Never had any issues like you’re describing.
dmazzoni 3y ago
I've worked on projects with thousands of developers committing to the same repo daily. Git is far from perfect, but in my experience it's been far superior to any of the alternatives I used before it (cvs, svn, p4).
TexasMick 3y ago
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.

hasty_pudding 3y ago

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

mikepurvis 3y ago
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 work is fundamentally hard to collaborate on or even really review. And never mind maintaining an ongoing integration of multiple unmerged feature branches— perhaps that's more of a "front end" issue for GitLab and Github to solve, but the whole business of patchsets and the like is very much unsolved, and that's painfully obvious when you see Debian storing their quilt patches inside of of a git repo, rather than being able to leverage git's native capabilities to achieve those effects: https://salsa.debian.org/debian/netplan.io/-/tree/debian/0.105-3/debian/patches https://salsa.debian.org/debian/netplan.io/-/tree/debian/0.1...
- TexasMick 3y ago
  You can always merge feature branches together to check for conflicts

dclowd9901 3y ago

I don’t understand how it isn’t easy? “git merge origin/master” Done. Unless you have a conflict, then fix it and commit. It couldn’t be simpler. If there’s value in this product, it won’t be because it’s somehow simpler than git.

withinboredom 3y ago

rerere has worked pretty well for me when handling conflicts and it’s built into git. I’ve worked with hundreds of engineers in a single codebase. Never had any issues like you’re describing.

dmazzoni 3y ago

I've worked on projects with thousands of developers committing to the same repo daily. Git is far from perfect, but in my experience it's been far superior to any of the alternatives I used before it (cvs, svn, p4).

TexasMick 3y ago

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.