In a git, etc. all ‘patches’/commits are ranked equally - anyone merging a emailed patch or a pull-request has no initial/first-approximation guidance on how much time/effort might be required to approve a merge.
These tools offer no assistance in a first-approximation prioritization of simple vs. more complex changes.
With it’s more formal graph-theoretic background perhaps Pijul could provide encode/decode complexity metrics?
Several are likely possible, so a repository creator could nominate one when the repository is created?
However, for an initial release, perhaps the p*c*log(h) metric for both is sufficient improvement?
Nonetheless, the following would be added to a change:
Complexity-Metric: ....
Complexity-Decode: ...
Complexity-Encode: ...
So for a first release:
Complexity-Metric: Big-Oh
Complexity-Decode: 123.456
Complexity-Encode: 123.456
Or some such.
Thoughts?
Actually, maybe for a first release, h could be more usefully be replaced by the number of dependencies the change has? In this case the change approximates a repository. Anyway, you get the idea.
Having the number of dependencies wouldn’t help much. There needs to be more help in managing the dependencies, and it’s not just about applying changes. Unrecording a change is quite cumbersome when other changes depend on it.
I wrote a script to visualize the dependencies, but it would be better is pijul would prompt for how to handle these or at the very least list them.
Maybe a way to list the number of lines affected, number of files affected, and/or dependencies would give an idea of the complexity of a change. (But line oriented numbers are for text files…)
All good points.
I was trying to avoid such arbitrary/random metrics - for no better reason than personal preference. While p*c*log(h) has some theoretical basis, there are likely other metrics - so I suppose we are actually back to making arbitrary choices 