Re: [PATCH v11 36/41] refs.c: move the check for valid refname to lock_ref_sha1_basic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 30, 2014 at 11:12 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> 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.)

Thanks.

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.

>
> Thanks,
> Jonathan
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]