This sounds like a proposal for general namespacing. I like it - that would pave the way for other header extensions - but that should probably be the subject of a separate proposal (who owns the content of a namespace, what is the process for adding a new namespace or a new attribute within a namespace, what order should the header attributes appear in, what problem is namespacing there to solve, when do we use a namespaced attribute versus a "reserved" attribute, etc.). x-evolve-pt seems reasonable to me. If you're keen on this and want to document the namespacing proposal, I'll conform to it. However, if don't have formal rules for namespaces in place yet it might be better to avoid the use of an x- prefix for now, just in case I accidentally squat on a name that breaks whatever namespacing rules we eventually come up with. Since we're talking bytes, a more compact representation of parent-type could use single-letter codes: x-evolve-pt c r o (where c=content, r=replace/obsolete, o=origin) - Stefan On Tue, Nov 20, 2018 at 1:43 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > On Tue, Nov 20 2018, Jonathan Nieder wrote: > > > Ævar Arnfjörð Bjarmason wrote: > >> On Thu, Nov 15 2018, sxenos@xxxxxxxxxx wrote: > > > >>> +Parent-type > >>> +----------- > >>> +The “parent-type” field in the commit header identifies a commit as a > >>> +meta-commit and indicates the meaning for each of its parents. It is never > >>> +present for normal commits. > > [...] > >> I think it's worth pointing out for those that are rusty on commit > >> object details (but I checked) is that the reason for it not being: > >> > >> tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 > >> parent aa7ce55545bf2c14bef48db91af1a74e2347539a > >> parent-type content > >> parent d64309ee51d0af12723b6cb027fc9f195b15a5e9 > >> parent-type obsolete > >> parent 7e1bbcd3a0fa854a7a9eac9bf1eea6465de98136 > >> parent-type origin > >> author Stefan Xenos <sxenos@xxxxxxxxx> 1540841596 -0700 > >> committer Stefan Xenos <sxenos@xxxxxxxxx> 1540841596 -0700 > >> > >> Which would be easier to read, is that we're very sensitive to the order > >> of the first few fields (tree -> parent -> author -> committer) and fsck > >> will error out if we interjected a new field. > > > > By the way, in the spirit of limiting the initial scope, I wonder > > whether the parent-type fields can be stored in the commit message > > initially. > > > > Elsewhere in this thread it was mentioned that the parent-type is a > > field to allow tools like "git fsck" to understand the meaning of > > these parent relationships (for example, to forbid a commit > > referencing a meta-commit). The same could be done using special > > commit message text, though. > > > > The advantage of such an approach would be that we could experiment > > without changing the official object format at all. If experiments > > revealed a different set of information to store, we could update the > > format without having to maintain the memory of the older format in > > "git fsck"'s understanding of commit object fields. So even though I > > think that in the end we would want to put this information in the > > commit object header, I'm tempted to suspect that the benefits of > > putting it in the commit message to start outweigh the costs (in > > particular, of having to migrate to another format later). > > I think it sounds better to just make it, in the header: > > x-evolve-pt content > x-evolve-pt obsolete > x-evolve-pt origin > > Where "pt = parent-type", we could of course spell that out too, but in > this case it's "x-evolve-pt" is the exact same number of bytes as > "parent-type", so nobody can object that it takes more space:) > > We'd then carry some documentation where we say everything except "x-*-" > is reserved, and that we'd like to know about new "*" there before it's > used, so it can be documented. > > Putting it in the commit message just sounds like a hack around not > having namespaced headers. If we'd like to keep this then tools would > need to parse both (potentially unpacking a lot of the commit message > object, it can be quite big in some cases...).
