From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: sxenos@google.com, git@vger.kernel.org, sbeller@google.com,
gitster@pobox.com, jonathantanmy@google.com, stolee@gmail.com,
carl@ecbaldwin.net, dborowitz@google.com
Subject: Re: [PATCH] technical doc: add a design doc for the evolve command
Date: Tue, 20 Nov 2018 10:43:31 +0100 [thread overview]
Message-ID: <87r2fgyth8.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20181120011841.GB62243@google.com>
On Tue, Nov 20 2018, Jonathan Nieder wrote:
> Æ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...).
next prev parent reply other threads:[~2018-11-20 9:43 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-15 0:55 [PATCH] technical doc: add a design doc for the evolve command sxenos
2018-11-15 12:52 ` Johannes Schindelin
2018-11-17 20:30 ` Stefan Xenos
2018-11-19 15:55 ` SZEDER Gábor
2018-11-19 21:32 ` Stefan Xenos
2018-11-20 1:09 ` Jonathan Nieder
2018-11-15 15:36 ` Ævar Arnfjörð Bjarmason
2018-11-20 1:18 ` Jonathan Nieder
2018-11-20 9:43 ` Ævar Arnfjörð Bjarmason [this message]
2018-11-20 17:45 ` Stefan Xenos
2018-11-20 22:06 ` Jonathan Nieder
2018-11-20 23:45 ` Stefan Xenos
2018-11-21 1:33 ` Jonathan Nieder
2018-11-21 19:10 ` Stefan Xenos
2018-11-16 21:36 ` Derrick Stolee
2018-11-17 23:44 ` Stefan Xenos
2018-11-17 6:06 ` Duy Nguyen
2018-11-18 22:27 ` Stefan Xenos
2018-11-18 22:29 ` Stefan Xenos
2018-11-18 23:20 ` Junio C Hamano
2018-11-17 7:36 ` Junio C Hamano
2018-11-19 0:36 ` Stefan Xenos
2018-11-19 2:15 ` Junio C Hamano
2018-11-19 3:33 ` Stefan Xenos
2018-11-19 3:45 ` Junio C Hamano
2018-11-19 4:15 ` Junio C Hamano
2018-11-19 20:14 ` Stefan Xenos
2018-11-19 20:26 ` Jonathan Nieder
2018-11-20 1:03 ` Junio C Hamano
2018-11-20 17:27 ` Stefan Xenos
2018-11-20 12:18 ` Phillip Wood
2018-11-20 12:59 ` Phillip Wood
2018-11-20 20:19 ` Stefan Xenos
2019-01-15 11:16 ` Phillip Wood
2018-11-20 13:03 ` Phillip Wood
2018-11-20 20:24 ` Stefan Xenos
2018-11-21 12:14 ` Phillip Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r2fgyth8.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=carl@ecbaldwin.net \
--cc=dborowitz@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=jrnieder@gmail.com \
--cc=sbeller@google.com \
--cc=stolee@gmail.com \
--cc=sxenos@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).