Duy Nguyen <pclo...@gmail.com> writes:
> Should the client side learn how to list hidden refs too? I'm thinking
> of an extreme case where upload-pack advertises nothing (or maybe just
> refs/heads/master) and it's up to the client to ask for the ref
> selection it's interested in. upload-pack may need more updates to do
> that, I think.
What you are talking about is a different goal.
Look at this as a mechanism for the repository owner to control the
clutter in what is shown to the intended audience of what s/he
publishes in the repository. Network bandwidth reduction of
advertisement is a side effect of clutter reduction, and not
necessarily the primary goal.
It lets me as the repository owner to say "do not list them to make
these discoverable"; letting the client side learn defeats the whole
point of this mechanism.
For example, if you mirror-clone from either of my repositories from
GitHub:
git clone --mirror git://github.com/git/git/
git clone --mirror git://github.com/gitster/git/
you will see stuff that does not belong to the project; objects that
are only reachable from refs/pull/* are not something I approved to
be placed in my repository; I as the project owner do not want to
give these objects to a cloner as if they are part of my project.
The server side can hide refs/pull/ and refs/pull-request-tags/ so
that clones (and ls-remote) will not see clutter, and nobody gets
hurt.
These refs are there only to support GitHub "pull requests"; the
advertisement of them to ls-remote and appearance of them in mirror
clones are undesirable side effects of how GitHub happened to
implement the feature. GitHub has its way to notify of these pull
requests, and it makes these pull requests discoverable out of band
without involving Git.
Ability to say "git fetch origin $SHA1" (or "git fetch origin
pull/1") is the only thing lacking, in order to get rid of these
clutter. The patches do the "get rid of clutter" part by letting
you hide these refs from ls-remote and clone; allowing "fetch by tip
SHA1" needs to come latter.
Another example. If you run ls-remote against the above two
repositories, you will notice that the latter has tons more
branches. The former are to publish only the primary integration
branches, while the latter are to show individual topics.
I wish I didn't have to do this if I could.
We have periodical "What's cooking" postings that let interested
parties learn topics out-of-band. If I can hide refs/heads/??/*
from normal users' clones while actually keeping individual topics
there at the same place, I do not have to push into two places.
--
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
