4 ms·

See also: https://news.ycombinator.com/item?id=25032956 https://news.ycombinator.com/item?id=25032956 Pijul is definitely a nice research project, and maybe so

by est31 3y ago

See also: https://news.ycombinator.com/item?id=25032956 https://news.ycombinator.com/item?id=25032956 Pijul is definitely a nice research project, and maybe some of the technology behind it could be integrated into better git tooling. But I doubt that exposing users to the raw "everything is just a bucket of patches, you have no history of repo state" idea is good. People want to be able to bisect, or check out some older version at a given time point. There are benefits of pijul's model, but I don't think they are worth as much as losing that.

deleted 3y ago
[deleted]
pkulak 3y ago
Wait, you can't see the state of the repository at an arbitrary point in time?
h0l0cube 3y ago
"bucket of patches" doesn't imply the patches couldn't be replayed to a point in time. Looking at the docs, you could probably use `log` and `unrecord` to go back to an earlier state. Or use `change` to view a particular change. https://pijul.org/manual/reference.html https://pijul.org/manual/reference.html
- est31 3y ago
  The issue is that `log` orders the patches by when they were made, not by when they were merged (in reality it might be a bit more detailed, probably a patch will always be ordered after the patches it depends on). git log also has parameters to configure it in that fashion, and it's also what github uses. However, importantly, git bisect does not use it. It uses the DAG of commits that git maintains. Yes, also git also only has a weak notion of a history of a branch: it is somewhat inside the titles of merge commits, and merge commits also have an order of their parents, so often you can just walk the first parent and always get to commits that used to be state of the master branch at a specific point in time. Sometimes it's even easier when merged PRs get squashed. But yeah, it's a bit implicit and if you e.g. rebase a PR then some of the commits in it have never been the tip of the master branch. But very importantly, every commit in git depends on every single commit that has contributed to that commit's tree. In pijul, they break up that property, and patches only depend on those patches which have directly modified the pieces of code that the change is editing. IIRC you can also manually introduce dependencies but those are rare. There isn't even a notion of a "patch's tree". You could construct a branch with only the patch and its dependencies but probably that wouldn't compile, and it will definitely not reflect the state of the branch at that point in time. You can make new branches in pijul that you don't modify and use like tags, but it is an explicitly requested thing. I mean, I see the elegance in pijul. Reverting a patch that has no conflicts and un-reverting it is trivial. But on the other hand, how often do you do that? Some workflows need patch based thinking, others need snapshot based thinking, and VCS tools need to master both, whether they start out with a snapshot history (like git) and then build diff based workflows on it (diff, rebase, etc), or whether they start out with a patch tree, and then build snapshot based workflows on it. pijul has weak snapshot based workflows, this part is still missing.
  - h0l0cube 3y ago
    The use cases define whether pijul is sufficient for your needs. For bisecting to find a bug, it seems you could easily bisect along a history of patches. Maybe there are patches that may alter the history that haven’t yet been merged, but that’s really an agreement between you and your collaborators that they should commit often. A similar constraint is required if you need to tag a commit for a release (where a snapshot can have meaningful implications for legal compliance, reproducible builds etc.)
    - est31 3y ago
      > it seems you could easily bisect along a history of patches. I've explained why this doesn't work in my comment above. Both a history of patches and bisect halting at the state of a specific patch are not things pijul supports: patches are only diffs so don't have "repo state", and are ordered only after their strict dependencies, i.e. those patches whose lines they modify.
      - h0l0cube 3y ago
        You could still isolate the changes that cause a problem, and it would still be reversing state in chronological order, but there might not be a one-for-one mapping between builds and the history, because the history can change upon merge. Though it's perhaps possible to freeze a channel for each build version, but I'll concede that seems like a hack.

by est31 3y ago

deleted 3y ago

[deleted]

pkulak 3y ago

Wait, you can't see the state of the repository at an arbitrary point in time?

h0l0cube 3y ago

"bucket of patches" doesn't imply the patches couldn't be replayed to a point in time. Looking at the docs, you could probably use `log` and `unrecord` to go back to an earlier state. Or use `change` to view a particular change. https://pijul.org/manual/reference.html https://pijul.org/manual/reference.html

est31 3y ago
The issue is that `log` orders the patches by when they were made, not by when they were merged (in reality it might be a bit more detailed, probably a patch will always be ordered after the patches it depends on). git log also has parameters to configure it in that fashion, and it's also what github uses. However, importantly, git bisect does not use it. It uses the DAG of commits that git maintains. Yes, also git also only has a weak notion of a history of a branch: it is somewhat inside the titles of merge commits, and merge commits also have an order of their parents, so often you can just walk the first parent and always get to commits that used to be state of the master branch at a specific point in time. Sometimes it's even easier when merged PRs get squashed. But yeah, it's a bit implicit and if you e.g. rebase a PR then some of the commits in it have never been the tip of the master branch. But very importantly, every commit in git depends on every single commit that has contributed to that commit's tree. In pijul, they break up that property, and patches only depend on those patches which have directly modified the pieces of code that the change is editing. IIRC you can also manually introduce dependencies but those are rare. There isn't even a notion of a "patch's tree". You could construct a branch with only the patch and its dependencies but probably that wouldn't compile, and it will definitely not reflect the state of the branch at that point in time. You can make new branches in pijul that you don't modify and use like tags, but it is an explicitly requested thing. I mean, I see the elegance in pijul. Reverting a patch that has no conflicts and un-reverting it is trivial. But on the other hand, how often do you do that? Some workflows need patch based thinking, others need snapshot based thinking, and VCS tools need to master both, whether they start out with a snapshot history (like git) and then build diff based workflows on it (diff, rebase, etc), or whether they start out with a patch tree, and then build snapshot based workflows on it. pijul has weak snapshot based workflows, this part is still missing.
- h0l0cube 3y ago
  The use cases define whether pijul is sufficient for your needs. For bisecting to find a bug, it seems you could easily bisect along a history of patches. Maybe there are patches that may alter the history that haven’t yet been merged, but that’s really an agreement between you and your collaborators that they should commit often. A similar constraint is required if you need to tag a commit for a release (where a snapshot can have meaningful implications for legal compliance, reproducible builds etc.)
  - est31 3y ago
    > it seems you could easily bisect along a history of patches. I've explained why this doesn't work in my comment above. Both a history of patches and bisect halting at the state of a specific patch are not things pijul supports: patches are only diffs so don't have "repo state", and are ordered only after their strict dependencies, i.e. those patches whose lines they modify.
    - h0l0cube 3y ago
      You could still isolate the changes that cause a problem, and it would still be reversing state in chronological order, but there might not be a one-for-one mapping between builds and the history, because the history can change upon merge. Though it's perhaps possible to freeze a channel for each build version, but I'll concede that seems like a hack.