Re: [PATCH 1/2] Move code resolving packed refs into its own function.
- From
Junio C Hamano <junkio@cox.net>
- Date
- Oct 3, 2006, 17:39 UTC
- Message-ID
- <7v4pulpad3.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <eftjua$2ii$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
Show 10 quoted lines
> Junio C Hamano wrote: > >> - I think gitweb should be Ok; it does peek-remote on the >> repository. Although we would probably want to update >> git_get_references and git_get_refs_list sub to use >> for-each-ref there, that can be done as a later optimization. > > I'd rather have gitweb use git-for-each-ref after the command > is in the official release... if not, then keep it in the 'next' > branch.
Of course. What else did you expect?
Show 5 quoted lines
> By the way, I have an idea to join the git-show-ref and git-for-each-ref:
> simply add --deref option to git-for-each-ref, which would output
> dereferenced tag just after the reference itself (well, perhaps with the
> exception when sorting, perhaps not), with the deref name like in
> git-show-ref and git-peek-remote, i.e. <ref>^{}Patches welcome. --verify needs to use totally separate codepath though. for-each-ref is primarily for easy displaying and expects the caller to script in order to skip ones that are irrelevant while listing (e.g. asking for *objectname does not error for a non-tag but the caller can deduce that ref is not a tag by it being empty and skip it); show-ref --verify is for easy checking for an exact match and should not even walk.