From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Tue, 02 Aug 2011 13:53:12 GMT
Subject: Re: Storing additional information in commit headers
Message-ID: <4E380148.7010701@alum.mit.edu>
In-Reply-To: <20110801182015.GA3100@fishbowl.rw.madduck.net>

On 08/01/2011 08:20 PM, martin f krafft wrote:
> 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?

Before you store important information in a git-internal data structure,
please consider:

* Some of your developers might prefer using another DVCS (e.g.,
Mercurial via hg-git) and they will not be able to see the information
at all

* Some day the main project might want to (god forbid!) switch to a
successor to git, and your extra information might be difficult to migrate.

* Somebody might want to work with your project from a tarball rather
than having to install and use git.

Therefore, I recommend a strong bias towards storing information in as
transparent, non-system-specific a way as possible.  Metadata and
scripts stored within the file tree part of the repository are typically
a lot easier to work with and more transparent than git-specific hacks.

That being said, I haven't understood your application well enough to
know whether these biases might be trumped by convenience in your
particular situation.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/