Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx> writes: > Yes, I was going to suggest exactly this, after Patrick pointed out > that there were only two 'special psuedo-refs' (I had a vague feeling > there were some more than that) FETCH_HEAD and MERGE_HEAD. Glad to see that I am not alone. We should be able to treat MERGE_HEAD similarly. It is used to communicate the list of "other parents" from "git merge" that stops in the middle (either for merge conflict, or in response to the "--no-commit" command line option) to "git commit" that concludes such an unfinished merge. Many commands merely use the presence of MERGE_HEAD as a sign that a merge is in progress (e.g. "git status"), which would not break if we just started to record the first parent in a pseudoref MERGE_HEAD and wrote the other octopus parents elsewhere, but some commands do need all these parents from MERGE_HEAD (e.g. "git blame" that synthesizes a fake starting commit out of the working tree state). If we cannot get rid of all "special refs" anyway, however, I think there is little that we can gain from doing such "make FETCH_HEAD and MERGE_HEAD into a single-object pseudoref, and write other info in separate files" exercise. We can treat the current FETCH_HEAD and MERGE_HEAD as "file that is not and is more than a ref", which is what the current code is doing anyway, which means we would declare that they have to stay to be files under $GIT_DIR/ and will be accessed via the filesystem access. At that point, calling them "special ref" might even be more misleading than its worth and we may be better off to admit that they are not even refs but a datafile some commands can use to obtain input from, but the phrase we use to refer to them, be it "special ref" or some random datafile, does not make a fundamental change on anything.
