On Thu, Feb 27, 2014 at 6:58 AM, Junio C Hamano <gits...@pobox.com> wrote: > Nguyễn Thái Ngọc Duy <pclo...@gmail.com> writes: > >> Note that logs/refs/.tmp-renamed-log is used to prepare new reflog >> entry and it's supposed to be on the same filesystem as the target >> reflog file. This is not guaranteed true for logs/HEAD when it's >> mapped to repos/xx/logs/HEAD because the user can put "repos" >> directory on different filesystem. Don't mess with .git unless you >> know what you're doing. > > Hmph. I am puzzled. > > We use TMP_RENAMED_LOG in rename_ref() in this sequence: > > * First move refs/logs/$oldname to TMP_RENAMED_LOG; > * Delete refs/$oldname; > * Delete refs/$newname if exists; > * Move TMP_RENAMED_LOG to refs/logs/$newname; > * Create refs/$newname. > > in rename_ref(), and TMP_RENAMED_LOG or the helper function > rename_tmp_log() that does the actual rename do not seem to be > called by any other codepath. > > How would logs/HEAD get in the picture? Specifically, I am not sure > if we ever allow renaming the HEAD (which typically is a symref but > could be detached) via rename_ref() at all.
HEAD is an exception, I agree. If you rename HEAD to something else, the repo will not be recognized anymore because HEAD is part of the repo signature. There are other refs outside refs/ though that can be renamed in theory. In practice all rename_ref() callers only operate on refs/ domain so this is a false alarm. -- Duy -- 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
