On Fri, May 30, 2014 at 11:12 AM, Jonathan Nieder <jrnie...@gmail.com> wrote:
> Ronnie Sahlberg wrote:
>> Move the check for check_refname_format from lock_any_ref_for_update
>> to lock_ref_sha1_basic. At some later stage we will get rid of
>> lock_any_ref_for_update completely.
> Do you know if this will cause any functional change?
> What is the potential impact? Is that impact worth it? (Given how
> broken the recovery codepaths currently are, I suspect this change is
> worth it, but it seems worth documenting in the log message.)
Updated the commit message to mention this.
This changes semantics for lock_ref_sha1_basic slightly. With this change
it is no longer possible to open a ref that has a badly name which breaks
any codepaths that tries to open and repair badly named refs. The normal refs
API should not allow neither creating nor accessing refs with invalid names.
If we need such recovery code we could add it as an option to git
fsck and have
git fsck be the only sanctioned way of bypassing the normal API and checks.
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