3 ms·
It also means cherry picking commits between branches prevents clean merging afterwards meaning you have to force yourself to keep branches short-lived. The pat
by lillecarl 5y ago
It also means cherry picking commits between branches prevents clean merging afterwards meaning you have to force yourself to keep branches short-lived. The patch graph pijul gives you doesn't have this issue. I'm not an expert, but when reading the Pijul blog it made a lot of sense for me.
- blagie 5y agoNo, that's mostly the fault of many bad decisions in the git user space. The data model is quite brilliant and quite general. It'd be possible to write a really good user space around the git data model if someone had the time and inclination. My personal gripes: * I like to commit every time I change a few lines of code. To have a clean version history, git requires me to rebase all of those commits. I'd like to have "major" and "minor" commits, which the git data model can support in several different ways (as a list, a tree, or DAG; I prefer the tree model). The user space makes anything like this incredibly painful. It encourages rewriting history, which is actually rather bad. * Large files are managed very, very badly. It's ironic since the git data model is ideal for things with large files. * Related, partial trees aren't really supported. This gives scaling issues. In many cases, I just want to work with a few files, or just the latest commit. Some of this is technically possible but practically painful enough to be not worthwhile. * Nested projects / submodules. Of those, only submodules might require changes to the underlying data model.