Re: Marking abandoned branches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano wrote:

> By the way, does gitweb still walk $GIT_DIR/refs hierarchy by
> hand to find out the set of refs?  When Linus is done with his
> refs/ work, that way would become unsupported.  You would need
> to read from "ls-remote $GIT_DIR".

Still, unfortunately. We could change git_get_references to use
'git ls-remotes $GIT_DIR' (or 'git --git-dir=$GIT_DIR ls-remotes .'),
and use git_get_references("refs/heads") in git_heads (and git_summary), 
and git_get_references("refs/tags") in git_tags. This _could_ be slower
than current implementation. git-show-refs would help a bit, but I'd rather
have git-show-refs in released version of git before using it in gitweb.

Moreover, git currently reads appropriate ref directly in
git_get_hash_by_ref, not supporting even symrefs, not to mention packed
refs. One solution would be to add support for symrefs and packed refs
directly in gitweb (Git.pm can help here), another to use git core command
(git-rev-parse?) but that can make gitweb slower (additional fork).

I hope that Linus work will be left to mature first in 'pu', then in 'next'
branch... wouldn't refs cache (similar to current index for files) be
better idea?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


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