Productivity aid

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.


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 :slight_smile: