Re: RFC/Pull Request: Refs db backend

From: David Turner <dturner@twopensource.com>
Date: Jun 23, 2015, 21:35 UTC
Message-ID: <1435095301.28466.76.camel@twopensource.com>
In-Reply-To: <1435089205.28466.56.camel@twopensource.com>

On Tue, 2015-06-23 at 15:53 -0400, David Turner wrote:

Show 16 quoted lines

> > * Regarding MERGE_HEAD: you take the point of view that it must continue
> > to be stored as a file. And yet it must also behave somewhat like a
> > reference; for example, `git rev-parse MERGE_HEAD` works today.
> > MERGE_HEAD is also used for reachability, right?
> > 
> > Another point of view is that MERGE_HEAD is a plain old boring
> > reference, but there is some other metadata related to it that the refs
> > backend has to store. The file-based backend would have special-case
> > code to read the additional data from the tail of the loose refs file
> > (and be sure to write the metadata when writing the reference), but
> > other backends could store the reference with the rest but do their own
> > thing with the metadata. So I guess I'm wondering whether the refs API
> > needs a MERGE_HEAD-specific way to read and write MERGE_HEAD along with
> > its metadata.
> 
> You are probably right that this is a good idea.

On reflection, I think it might make sense to keep MERGE_HEAD as a file. The problem is that not only would refs backends have to add new MERGE_HEAD-handling functions, but we would also need new plumbing commands to allow scripts to access the complete contents of MERGE_HEAD. That seems more complicated to me.