also sprach Junio C Hamano <gitster@xxxxxxxxx> [2009.02.13.0735 +0100]: > Once you start making each case arm do more things, it might make sense to > rewrite the above unrolled loop into something like this: [...] > } ref_kind[] = { > { REF_LOCAL_BRANCH, "refs/heads/", 11 }, > { REF_REMOTE_BRANCH, "refs/remotes/", 13 }, > }; [...] > Then we can later add new elements more easily, e.g. > > { REF_TOPGIT_BASE, "refs/top-base/", 14 }, As soon as TopGit is integrated into Git proper, this could make sense. However, I don't know when this will happen. In the mean time, hardcoding extensions like you suggest might not scale too well. Wouldn't it make more sense to provide an interface that allowed tools to register their own namespaces, and handle those appropriately within Git? Much of that handling could be taken straight from refs/remotes/*, as they are conceptually the same. refs/remotes/* just has additional treatment inside Git, because it's part of the basic feature set. An external feature's namespace wouldn't be, but Git also doesn't need to know anything about those, or treat them specially. -- martin | http://madduck.net/ | http://two.sentenc.es/ "doesn't he know who i think i am?" -- phil collins spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)