From: Junio C Hamano <gitster@pobox•com>
To: David Turner <dturner@twopensource•com>
Cc: Michael Haggerty <mhagger@alum•mit.edu>,
git mailing list <git@vger•kernel.org>
Subject: Re: RFC/Pull Request: Refs db backend
Date: Tue, 23 Jun 2015 14:41:08 -0700 [thread overview]
Message-ID: <xmqqwpyuayrv.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1435095301.28466.76.camel@twopensource.com> (David Turner's message of "Tue, 23 Jun 2015 17:35:01 -0400")
David Turner <dturner@twopensource•com> writes:
> On Tue, 2015-06-23 at 15:53 -0400, David Turner wrote:
>> > * 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.
I think you are talking about FETCH_HEAD, but I tend to agree.
next prev parent reply other threads:[~2015-06-23 21:41 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-23 0:50 RFC/Pull Request: Refs db backend David Turner
2015-06-23 5:36 ` Junio C Hamano
2015-06-23 10:23 ` Duy Nguyen
2015-06-23 18:47 ` David Turner
2015-06-23 17:29 ` David Turner
2015-06-23 11:47 ` Jeff King
2015-06-23 13:10 ` Duy Nguyen
2015-06-24 8:51 ` Jeff King
2015-06-23 18:18 ` David Turner
2015-06-24 9:14 ` Jeff King
2015-06-24 17:29 ` David Turner
2015-06-24 6:09 ` Shawn Pearce
2015-06-24 9:49 ` Jeff King
2015-06-25 1:08 ` brian m. carlson
2015-06-24 10:18 ` Duy Nguyen
2015-06-23 15:51 ` Michael Haggerty
2015-06-23 19:53 ` David Turner
2015-06-23 21:27 ` Michael Haggerty
2015-06-24 17:31 ` David Turner
2015-06-23 21:35 ` David Turner
2015-06-23 21:41 ` Junio C Hamano [this message]
2015-06-23 17:16 ` Stefan Beller
2015-06-23 20:04 ` David Turner
2015-06-23 20:10 ` Randall S. Becker
2015-06-23 20:22 ` David Turner
2015-06-23 20:27 ` Randall S. Becker
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=xmqqwpyuayrv.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=dturner@twopensource$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=mhagger@alum$(echo .)mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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