Nested grouping of commits?

[gilescope]

I commit a change. Then a few more associated changes as additional commits.

A few of these change sets represent a feature.

In git one might merge that feature to master with a squash to hide all the nitty gritty details of the construction to keep a clean log.

I would love for the log to contain the feature commit, but to be able to drill down and see inside that if need be the commits that made that up (and drill down inside those commits if need be)… all nicely nested.

Is nested grouping of commits something that piju support currently or might in the future?

Does what I’m asking for make sense to you? I feel that if we could construct hierarchically sets of patches this could be a beautiful thing.

[hyperfekt]

I would argue it is worth exploring this as a first-class concept, given how much of an improvement it offers over the git model of just amending and/or squashing for a clean history. It seems there is a semantic difference between nesting patches by level of detail, versus to maintain chronology, where constituents of the latter should probably be hidden by default.

[joyously]

You are describing what Bazaar does by default. See https://duckrowing.com/2013/12/26/bzr-init-a-bazaar-tutorial/ for the comparison with git, hg, and bzr. And this for a little tutorial on the nested logs: https://bzrinit.com/02.html
This seems like a good goal for Pijul. I also prefer Bazaar’s way of naming revisions sequentially instead of a hash, but I get why it is the way it is now.

[fyr]

Nonglobal identifiers in a noncentralized system seem extremely confusing to try to communicate about. “Oh did you try the build at - well, my machine says it’s commit 2413”

(Global hashes of patches themselves, as in pijul, at least let you talk about the changes you’re reviewing / have bisected to be responsible for a bug / etc)

[no_identd]

Patching patches

Here is a feature that someone suggested to me today: patches that operate on other patches rather than on the direct text. One potential implementation (but I have other ideas as well) could be to represent some patches as plain text files, added to the repository as normal files (for example in a patches directory at the top level), and patchable themselves. When a patch is patched, a cascade of unrecords + application of the new version would follow (the cascade is needed because this would …

[pmeunier]

I don’t want that feature anymore. Two improvements have made it redundant: (1) a canonical text representation of patches in the new Pijul, and (2) arbitrary metadata fields in the patches.