4 ms·

Not having to worry about the order of patches would (except where they explicitly depend on each other) is a really nice property to have. One consequence of t

Not having to worry about the order of patches would (except where they explicitly depend on each other) is a really nice property to have. One consequence of this property, alluded to in the article, is that if I understand correctly, rebasing and merging effectively become the same operation. In Git, the difference between rebasing and merging is the resulting dependency graph of the commits. However, in Pijul, there is no dependency graph, at least not based on the order in which the commits are applied, so rebase and merge are equivalent. For example, have you ever been doing code-review on a Github pull request and made an inline comment on a line of code, only to have that comment later invalidated by a rebase? That happens because the commit hashes were changed by the rebase, so the commit hash referenced by that comment is no longer contained in the pull request. There's probably a new commit with a new commit hash representing the same change, but there doesn't have to be. So Github can no longer be certain of where to place that comment, and it can't tell you whether that comment is still relevant to the pull request in its current state. (IIRC, Github continues to show such comments but marks them as associated with commits that are no longer in the branch, which makes it hard to know if they're still applicable.) In Pijul, I'm pretty sure this problem simply doesn't exist. A hypothetical "Pijulhub" that implemented the same "comment on changes" feature could certainly have comments on old changes that subsequently get removed from the pull request, but if that happens, then "Pijulhub" can confidently declare that those comments are no longer relevant to the current state. On the other hand, if some version of the same change is still present in the current state of the pull request, then "Pijulhub" can confidently continue to include that comment, still associated with that same change, because even after modifying the pull request, that change still has the same hash, because it still represents the exact same change.

ithkuil 6y ago
> A hypothetical "Pijulhub" that implemented the same "comment on changes" A "pijulhub" ready exists and it's called "Nest". There is still a lot of work to do but at least it has a name :-)
pmeunier 6y ago
About your guess on the Pijul hub: nest.pijul.com does something nicer than PRs, which is to attach changes independent from the context, to discussions. See the following discussion, for example: https://nest.pijul.com/pijul/pijul/discussions/104 https://nest.pijul.com/pijul/pijul/discussions/104 These two contributors (@cole-h and @lowenheim) are trying to add colours to the output of `pijul change`, and discuss changes, rewrite them, amend them, push them again. Certainly, some of these changes conflict with others. But that's totally ok, since you can pull them independently. For example, when preparing release 1.0.0-alpha.9, I didn't pull the latest patch from that discussion into my main local channel, and I preferred to pull some of the older ones instead. I did this because the latest one doesn't detect whether the standard output is a TTY. If I apply them to the main channel on the Nest, my current local channel will be in sync with it, even though I've worked on ten other features since then.
- rcthompson 6y ago
  Yeah, this is why I talked about a hypothetical "Pijulhub", instead of talking about any real website. The hypothetical website I'm comparing to would be one that replicates Github's features as closely as possible but uses Pijul as the VCS. But as you say, the real answer is that a hub for Pijul should be built around the data model and features of Pijul, not those of Git.

ithkuil 6y ago

> A hypothetical "Pijulhub" that implemented the same "comment on changes" A "pijulhub" ready exists and it's called "Nest". There is still a lot of work to do but at least it has a name :-)

pmeunier 6y ago

About your guess on the Pijul hub: nest.pijul.com does something nicer than PRs, which is to attach changes independent from the context, to discussions. See the following discussion, for example: https://nest.pijul.com/pijul/pijul/discussions/104 https://nest.pijul.com/pijul/pijul/discussions/104 These two contributors (@cole-h and @lowenheim) are trying to add colours to the output of `pijul change`, and discuss changes, rewrite them, amend them, push them again. Certainly, some of these changes conflict with others. But that's totally ok, since you can pull them independently. For example, when preparing release 1.0.0-alpha.9, I didn't pull the latest patch from that discussion into my main local channel, and I preferred to pull some of the older ones instead. I did this because the latest one doesn't detect whether the standard output is a TTY. If I apply them to the main channel on the Nest, my current local channel will be in sync with it, even though I've worked on ten other features since then.

rcthompson 6y ago
Yeah, this is why I talked about a hypothetical "Pijulhub", instead of talking about any real website. The hypothetical website I'm comparing to would be one that replicates Github's features as closely as possible but uses Pijul as the VCS. But as you say, the real answer is that a hub for Pijul should be built around the data model and features of Pijul, not those of Git.