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.
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

Reply via email to