David Turner <dtur...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
