"Lars Hjemli" <lh@xxxxxxxxxxxxxxxxx> writes: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html