git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: martin f krafft <madduck@madduck.net>
Cc: git discussion list <git@vger.kernel.org>,
	Petr Baudis <pasky@ucw.cz>, Clemens Buchacher <drizzd@aon.at>
Subject: Re: Storing additional information in commit headers
Date: Mon, 1 Aug 2011 14:13:01 -0600	[thread overview]
Message-ID: <20110801201301.GA17111@sigill.intra.peff.net> (raw)
In-Reply-To: <20110801182015.GA3100@fishbowl.rw.madduck.net>

On Mon, Aug 01, 2011 at 08:20:15PM +0200, martin f krafft wrote:

> Instead, I am investigating ways in which I can store additional
> information for a branch, and ideally in a way to make it
> transparent and automatic for all users of a project's repo.
> 
> Hence, if I were to store additional information in the commit
> object headers, this information would by design be correct,
> immutable, and non-redundant. I am going to reply to my own mail
> with some implementation details to feed the curious, with the hope
> to keep this debate focused.
> 
> Are there any strong reasons against my use of commit headers for
> specific, well-defined purposes in contained use-cases? E.g. are
> there tools known to only copy "known" headers, which could
> potentially break my assumptions?

This topic has come up several times in the past few years. I think some
of the relevant questions to consider about your new data are:

  1. Does git actually care about your data? E.g., would it want to use
     it for reachability analysis in git-fsck?

  2. Is it an immutable property of a commit, or can it be changed after
     the fact?

If (2) is no, then git-notes is probably the best choice.

Otherwise, if (1) is yes, then a commit header makes sense. But then, it
should also be something that git is taught about, and your commit
header should not be some topgit-specific thing, but a header showing
the generalized form.

Otherwise, the usual recommendation is to use a pseudo-header within the
body of the commit message (i.e., "Topgit-Base: ..." at the end of the
commit message). The upside is that it's easy to create, manipulate, and
examine using existing git tools. The downside is that it is something
that the user is more likely to see in "git log" or when editing a
rebased commit message.

Just about every discussion on this topic ends with the pseudo-header
recommendation. The only exceptions AFAIK are "encoding" (which git
itself needs to care about), and "generation" (which, as you noted,
raises other questions).

-Peff

  parent reply	other threads:[~2011-08-01 20:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-01 18:20 Storing additional information in commit headers martin f krafft
2011-08-01 18:27 ` Sverre Rabbelier
2011-08-01 18:34   ` martin f krafft
2011-08-01 20:01     ` Clemens Buchacher
2011-08-01 20:55       ` martin f krafft
2011-08-01 18:28 ` martin f krafft
2011-08-01 19:33   ` Martin Langhoff
2011-08-01 20:51     ` martin f krafft
2011-08-01 20:13 ` Jeff King [this message]
2011-08-01 21:11   ` martin f krafft
2011-08-02  3:50     ` Jeff King
2011-08-02  8:28       ` martin f krafft
2011-08-02 15:03         ` working prototype of orphan parent commits as datastores (was: Storing additional information in commit headers) martin f krafft
2011-08-02 18:57           ` Jeff King
2011-08-02 19:09             ` martin f krafft
2011-08-02 19:26               ` martin f krafft
2011-08-02 18:51         ` Storing additional information in commit headers Jeff King
2011-08-02 19:06           ` martin f krafft
2011-08-02 19:27             ` per-ref data storage (was: Storing additional information in commit headers) martin f krafft
2011-08-02 21:12               ` per-ref data storage martin f krafft
2011-08-04  3:41               ` per-ref data storage (was: Storing additional information in commit headers) Jeff King
2011-08-04  3:39             ` Storing additional information in commit headers Jeff King
2011-08-02 13:53 ` Michael Haggerty

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110801201301.GA17111@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=drizzd@aon.at \
    --cc=git@vger.kernel.org \
    --cc=madduck@madduck.net \
    --cc=pasky@ucw.cz \
    /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.
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 NNTP newsgroup(s).