Michael Haggerty <mhag...@alum.mit.edu> writes:

> On 08/20/2014 09:45 PM, Junio C Hamano wrote:
>> Michael Haggerty <mhag...@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.


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

Reply via email to