On 2025-02-13 at 08:22:21, Jeff King wrote: > Yes, we do similarly spend a lot of time there. But the problem isn't > quite that repo_get_oid() also parses revisions. When we see a full > object id we return it quickly. But you can fall afoul of 798c35fcd8 > (get_sha1: warn about full or short object names that look like refs, > 2013-05-29), which does a full dwim_ref() lookup for each one! > > Try: > > git -c core.warnAmbiguousRefs=false update-ref --stdin > > to disable that. Internally there's a warn_on_object_refname_ambiguity > flag that some code (like cat-file) sets when it knows it may be asked > to do a resolve a lot of entries that are likely to be oids. Yeah, I think both of these would be great improvements. The kind of case I'm interested in is reference updates in the context of pushes or various API calls, where we're always going to have a full object ID and there is never a human connected to the output of Git. I expect that is the case for a lot of users. I also think it's unlikely that even the general scripter who's working with `git update-ref` is going to want that warning. Most users of that command are GUIs, APIs, server backends, or the like, and even if I used the command in my Git aliases or some custom commands, I still wouldn't really care for that kind of extra output. I _do_ always want screaming performance in `git update-ref` though, since I frequently, even in my everyday scripting, work with large numbers of refs. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
