Re: [PATCH v20 43/48] 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 08/20/2014 09:45 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> 
>> I think we can get away with not including broken refnames when
>> iterating.  After all, the main goal of tolerating them is to let them
>> be deleted, right?
> 
> Or read from a ref whose name has retroactively made invalid, in
> order to create a similar but validly named ref to serve as its
> replacement?  So at least we need to give the users some way of
> reading from them, in addition to deleting them, no?

The die() error message would presumably include the name of the invalid
reference.

If we change the rules for reference names and a bunch of names become
invalid, then it would admittedly be cumbersome to run git N times to
find the N invalid names.  But if we change the rules, then *at that
time* we could always build in iteration over broken reference names.

It's not that I have something against building it iteration over broken
reference names now, as long as it is clearly segregated from "normal"
iteration to prevent illegal names from getting loose in the code.

Michael

-- 
Michael Haggerty
mhagger@xxxxxxxxxxxx

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