Nested grouping of commits?

Question
1

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.

4 Likes
2

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.

2 Likes
3

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.

4

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)

5

:thinking:

6

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.

1 Like
7

Was the arbitrary metadata feature implemented / kept? If yes, how is it supposed to be used?

8

In a change, you can write arbitrary bytes in the following field:

If you don’t want it to be hashed (for example because it references the hash of the patch itself, you can also add stuff to a toml structure in the unhashed section:

The reason for arbitrary bytes in the hashed part is that the hashed part is very dependent on the precise byte representation of things, and this format allows one to customise patches for a specific application, whereas the unhashed section is meant more for common extensions to Pijul patches, such as PGP signatures, and the TOML format avoids having different extensions stepping on each other’s feet.

9

I don’t know about anyone else, but linking to the code docs doesn’t seem to me to answer the question about how to use it.

10

Yeah, I actually found those pieces of code. :sweat_smile: I tried adding a section titled “# Metadata” to a patch record, but it doesn’t seem like pijul change or log shows any sign that it made it into the actual patch…

11

Right, they aren’t parsed at all:

  • for the metadata, they’re arbitrary bytes, and are meant for domain-specific extensions.
  • for the unhashed bits, it wouldn’t make sense to parse them, since the parsed text is the hashed thing.

What are you trying to do?

12

I was thinking it might be relevant for the workflows section in the manual. I think rather not :wink: