Re: How to add custom metadata to Git commit object
- From
Kirill Likhodedov <kirill.likhodedov@jetbrains.com>
- Date
- May 31, 2016, 15:17 UTC
- Message-ID
- <A5ADADA5-B772-488E-8FAD-20FCB68E5933@jetbrains.com>
- In-Reply-To
- <xmqqtwhf8jl7.fsf@gitster.mtv.corp.google.com>
Thanks a lot for your suggestions!
> And "the user can use notes for other purposes" is not a good reason > to reject them. The whole point of allowing custom notes ref is so > that Kirill is not restricted to use the usual notes/commits ref to > store this custom notes in its dedicated notes/kirills-metadata ref.
I think the suggestion from Junio will suit best. Somehow I missed the fact that notes can reside in several namespaces. Now I see that the notes are very powerful having namespaces and several configuration and environment variables.
Jeff,
Show 5 quoted lines
> there are user-invisible headers before the commit message, too, but we do not > usually recommend people to add new headers here, as their semantics > would be unclear to git. For example, when rebasing such a commit, > should the header be preserved or not? It depends on its meaning. > Whereas commit messages are always preserved.
Good point about rebase. Just out of curiosity, is it possible to add a custom invisible header to commit object with some Git command? git commit or commit-tree don’t have an option for this.
Show 22 quoted lines
> On 30 May 2016, at 21:52 , Junio C Hamano <gitster@pobox.com> wrote: > > Jeff King <peff@peff.net> writes: > >> On Mon, May 30, 2016 at 08:58:08PM +0300, Kirill Likhodedov wrote: >> ... >>> There are git-notes, which could be used for the purpose, but they are >>> visible to the user via standard Git command, and could be used by the >>> user for other purposes, so they are not very suitable for the task. >> >> Notes would work for this, too, but their main advantage is that they >> can be created _after_ a commit has already been made (whereas anything >> in the commit object itself will influence its sha1 id). > > I would have said the same but with s/but/and/. If the "rename > hint" or whatever other "custom metadata" Kirill gives to a commit > is found to be wrong, it can be corrected later. > > And "the user can use notes for other purposes" is not a good reason > to reject them. The whole point of allowing custom notes ref is so > that Kirill is not restricted to use the usual notes/commits ref to > store this custom notes in its dedicated notes/kirills-metadata ref.