"Lars Hjemli" <lh@elementstorage.no> writes:

quoted text
> Is it ok to put
>
> static int log_ref_write(struct ref_lock *lock,
> 	const unsigned char *sha1, const char *msg)
>
> into refs.h?

I think a cleaner implementation that does not have such a
layering violation would involve defining rename_refs()
interface in refs.c, next to the delete_ref() that exists there.

The division of labor would be for builtin-branch.c to make sure
both oldname and newname are branch names, and rename_refs() to
rename the reflog (if exists) and the ref at the same time.  To
deal with D/F conflicts sanely, I suspect it would involve a
call to rename(2) to move the reflog to a temporary location,
perhaps $GIT_DIR/.tmp-renamed-log, deletion of the old ref by
calling delete_ref(), and then another rename(2) to move that
temporary one to its final location, followed by the usual "ref
creation dance" of calling lock_any_ref_for_update() and
write_ref_sha1().

Side note:

If we do not mind losing the reflog of oldname, then "delete and
then create" would be sufficient, but that is not the case.

Unlike "git does not track individual files so we do not record
renames" mantra, branches, and more in general, refs, have
meaningful identity (at least locally), and unlike the file
contents, the "contents" of a ref does not migrate _partially_
from ref to ref.  It would make sense to keep track of renames
for them.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html