3 ms·

This seems really nice. git got the data model really right, and the user space really wrong. The data model is more important than the user space. This is th

by blagie 5y ago

This seems really nice. git got the data model really right, and the user space really wrong. The data model is more important than the user space. This is the first project I've seen which appears to understand and respect /how/ and /why/ the git data model is so elegant.

lillecarl 5y ago
The pijul model makes even more sense to my brain, being patch based solves a lot of branching issues.
- blagie 5y ago
  One of the many breakthroughs in git was precisely not being patch based. Being patch-based means that the tools for comparing versions are hard-coded into the data format. One of the major upsides of CVS->SVN, for example, was support for file moves. Simple issues like this weren't possible to fix without reworking the whole system. With a version-based model, how you compare them is determined by the user space, whether that's merges, or viewing history. Even compression isn't all that fundamental to much of anything; it's possible to implement underneath the system, eliminating whatever redundancy you want. With patch-based systems, all of that comes baked into the underlying representation. On a deeper level, this feeds into how git can be distributed, robust, yet very simple.
  - 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 ago
      No, 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.
dane-pgp 5y ago
> The data model is more important than the user space. For those interested in the different perspectives on how to weigh those priorities, I recommend starting here: https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better
- somebodythere 5y ago
  I think the programmer tendency to think of usability as an implementation detail is probably why open-source app UX was considered a joke for so many years. Only now is that perception starting to change, because enough people have taken an interest in the space who make usability a priority.
  - antifa 5y ago
    More like, people who've taken an interest in the space are having a much harder time finding jobs that aren't "fill this electron app/SaaS with dark patterns."

by blagie 5y ago

lillecarl 5y ago

The pijul model makes even more sense to my brain, being patch based solves a lot of branching issues.

blagie 5y ago
One of the many breakthroughs in git was precisely not being patch based. Being patch-based means that the tools for comparing versions are hard-coded into the data format. One of the major upsides of CVS->SVN, for example, was support for file moves. Simple issues like this weren't possible to fix without reworking the whole system. With a version-based model, how you compare them is determined by the user space, whether that's merges, or viewing history. Even compression isn't all that fundamental to much of anything; it's possible to implement underneath the system, eliminating whatever redundancy you want. With patch-based systems, all of that comes baked into the underlying representation. On a deeper level, this feeds into how git can be distributed, robust, yet very simple.
- 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 ago
    No, 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.

dane-pgp 5y ago

> The data model is more important than the user space. For those interested in the different perspectives on how to weigh those priorities, I recommend starting here: https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better

somebodythere 5y ago
I think the programmer tendency to think of usability as an implementation detail is probably why open-source app UX was considered a joke for so many years. Only now is that perception starting to change, because enough people have taken an interest in the space who make usability a priority.
- antifa 5y ago
  More like, people who've taken an interest in the space are having a much harder time finding jobs that aren't "fill this electron app/SaaS with dark patterns."