Re: [PATCH] technical doc: add a design doc for the evolve command

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Nov 20, 2018, 09:43 UTC
Message-ID: <87r2fgyth8.fsf@evledraar.gmail.com>
In-Reply-To: <20181120011841.GB62243@google.com>

On Tue, Nov 20 2018, Jonathan Nieder wrote:

Show 45 quoted lines

> Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Nov 15 2018, sxenos@google.com 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@gmail.com> 1540841596 -0700
>>     committer Stefan Xenos <sxenos@gmail.com> 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...).