Ask HN: Can we do better than Git for version control?

1

Pijul

Not only merge conflicts I find that this causes trouble if you need to manage multiple branches. Generally you see patterns like 1. Create patch 2. Merge to main branch 3. Backport a cherry pick. But there is no machine-readable metadata that the commit is the same in both cases. In simple cases you can work around this by basing the patch off of the merge base but if there are conflicts that doesn't work well. The result of this is that these two different but logically identically commits will cause future merge conflicts and make questions like "does this branch have this patch" much more difficult to answer. This is something that I think https://pijul.org/ does quite well. Their base unit is a patch and that can be applied to multiple places. You can also have snapshots which are logically a collection of patches.

#Git #Code Collaboration #Git Tools 41 social mentions

2

Sapling SCM

Yep both extended it and have versions that can work against GitHub/git servers. Sapling scm from meta has I think the best cli and VS code UX https://sapling-scm.com/ jj from google is also mercurial derived with very similar cli features like histedit and has support for deferring conflict resolution <a href="https://github.com/martinvonz/jj">https://github.com/martinvonz/jj</a>.

#Git #Code Collaboration #Git Tools 13 social mentions

3

darcs

Perforce. As for DVCS, the best one I've used is Darcs: https://darcs.net/ There are some sticky wickets (specifically, exponential-time conflict resolution) that hindered its adoption. Thankfully, there's Pijul, which is like Darcs but a) solves that problem; and b) is written in Rust! The perfect DVCS, probably! https://pijul.org/.

#Git #Code Collaboration #Git Tools 4 social mentions

4

Git Large File Storage

#Git #Development #Code Collaboration 100 social mentions

5

lazygit

Yes, but due to its simplicity + extensibility + widespread adoption, I wouldn’t be surprised if we’re still using Git 100+ years from now. The current trend (most popular and IMO likely to succeed) is to make tools (“layers”) which work on top of Git, like more intuitive UI/patterns (https://github.com/jesseduffield/lazygit) and smart merge resolvers (https://github.com/Symbolk/IntelliMerge). Git it so flexible, even things that it handles terribly by default, it handles.

#Git #Git Tools #Development 81 social mentions

6

Fork

As the OP, along what axis do you want the VCS to be "better" than git? git's cli user interface is monstrous (yes, I know, you personally have 800 cli commands memorized and get them all right every time, that doesn't make it "good"). From the outset, the maintainers of got basically decided "it's too much work to make all the cli flags behave and interact consistently" so they didn't. This allowed git to grow fast, at the cost of cli user experience. That said, git is big enough that multiple companies have come along and "solved" the git UI problem. None of these aftermarket UI layers are perfect, but there are enough of them and they are different enough that you can probably find one that is good enough for you, along whatever axis you personally dislike the git UI (examples include [0] and [1], which tackle very different user workflow problems). [0] https://git-fork.com/ [1] https://graphite.dev/.

#Git #Git Tools #Git Client 84 social mentions

7

GitHub Desktop

- Product designers for open-source hardware. Various design files, SVG etc. I’ve experimented with a “GUI only” git flow - just to see what is possible, so I could introduce the concept to others. I found GitHub desktop app (https://desktop.github.com/)did a great job of visually showing git flows and functions, but for a non-tech/programmming person, the tool would be daunting. Curiosity what your suggested tech stack would be - sans Terminal….

#Git #Git Tools #Code Collaboration 129 social mentions