Re: [PATCH v20 43/48] refs.c: move the check for valid refname to lock_ref_sha1_basic
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 20, 2014, 21:24 UTC
- Message-ID
- <xmqqy4uisvlk.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <53F500E9.6060900@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 23 quoted lines
> On 08/20/2014 09:45 PM, Junio C Hamano wrote: >> Michael Haggerty <mhagger@alum.mit.edu> 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.
Oh, I don't think it is that important for iterator to show broken ones. If refs/heads/foo/$brokenname exists but is skipped from any and all iterations, nobody will get hurt until the end user wonders where foo/$brokenname went, at which time rev-parse can be used to grab the value from it before update-ref -d can be used to remove it.
If refs/heads/foo/$brokenname, which is skipped from iterations, prevents a valid ref refs/heads/foo from getting created, that would give a bit of surprise to the user who long forgot foo/$brokenname existed, but the recovery procedure is exactly the same as the case where he has a branch foo/$koshername and wants to create foo; first 'branch -D' the D/F-conflicting one and then create foo.
So the primary things I care about are when the user has a string that is the name of an existing misnamed ref, the value of the ref can be obtained, and the ref can be removed.
Thanks.