5 ms·

> As far as I understand, the main change with respect to Git is that commit hashes don't change depending on previous history, so if you rebase the same change

> As far as I understand, the main change with respect to Git is that commit hashes don't change depending on previous history, so if you rebase the same change IDs are retained. That is not the main change, merely a by-product. There are many changes: - Perhaps one of the most crucial differences is that Pijul uses a rigorous merge algorithm, and doesn't run into the bad merge examples described in [1]. Note that the situation described there happens without any conflict, and doesn't tell anything to the user. - Changes that could be written independently commute, meaning that they can be pushed independently. You don't have to worry about isolating them on feature branches, which can save time if you (like me) work on many features at the same time. - Rebase and Merge are the same operation in Pijul, and happens automatically. Conflicts happen between changes, and conflict resolutions are recorded as changes, so you don't need any `git rerere` (which essentially guesses what to do), since conflict resolutions work even in a different context. - Everything is invertible! You can even remove an old change from a channel if you like, as long as other changes don't depend on it. > I don't like that two repositories in different states could have the same commit ID. That never happens in Pijul. Changes are not commits, they're diffs between commits. And states have identifiers too, they're just more subtle: if you have two changes A and B, Pijul can apply them in any order without changing the result (so why change the commit id?). In Pijul, if you run `pijul log --state`, on "A, then B" and "B, then A", you will get the same state id. [1] https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html

vbrandl 6y ago
If the order of changes does not matter and identifiers do not depend on previous changes, ist there still a way to uniquely identify a specific set of changes? With git, I like to include the commit ref in release binaries which is great for debugging since I can just git checkout and see the exact form of the code running on the server. Is there something similar in pijul?
- dan-robertson 6y ago
  From reading the blog posts/source code, I can explain how it works. Here’s a simple way to give a set of changes (a state) an id: 1. Take the hashes of each change 2. XOR them together 3. This is your state ID. The problem is that because of the way you’ve made it (basically adding a bunch of vectors in a vector space over F2), one could use Gaussian elimination to construct any given ID without it being of the intended set of changes. Therefore pijul uses a process which works similarly but in a more cryptographically secure way which makes forging state IDs harder.
- gnufx 6y ago
  I assume it's the same as with Darcs, where you would record a tag patch. The darcs --exact-version option prints that for a released version of darcs.

vbrandl 6y ago

If the order of changes does not matter and identifiers do not depend on previous changes, ist there still a way to uniquely identify a specific set of changes? With git, I like to include the commit ref in release binaries which is great for debugging since I can just git checkout and see the exact form of the code running on the server. Is there something similar in pijul?

dan-robertson 6y ago
From reading the blog posts/source code, I can explain how it works. Here’s a simple way to give a set of changes (a state) an id: 1. Take the hashes of each change 2. XOR them together 3. This is your state ID. The problem is that because of the way you’ve made it (basically adding a bunch of vectors in a vector space over F2), one could use Gaussian elimination to construct any given ID without it being of the intended set of changes. Therefore pijul uses a process which works similarly but in a more cryptographically secure way which makes forging state IDs harder.
gnufx 6y ago
I assume it's the same as with Darcs, where you would record a tag patch. The darcs --exact-version option prints that for a released version of darcs.