On 01/30/2013 07:45 PM, Junio C Hamano wrote:
> The third round.
>
> - Multi-valued variable transfer.hiderefs lists prefixes of ref
> hierarchies to be hidden from the requests coming over the
> network.
>
> - A configuration optionally allows uploadpack to accept fetch
> requests for an object at the tip of a hidden ref.
>
> Elsewhere, we discussed "delaying ref advertisement" (aka "expand
> refs"), but it is an orthogonal feature and this "hiding refs
> completely from advertisement" series does not attempt to address.
>
> Patch #2 (simplify request validation), #4 (clarify the codeflow),
> and #5 (use struct ref) are new. The are all long overdue clean-ups
> for these codepaths.
>
> The last patch is an illustration why it wouldn't make sense to
> optionally allow pushing into hidden refs, and not meant to be part
> of the series proper.
>
> For those who missed it, earlier rounds are at:
>
> http://thread.gmane.org/gmane.comp.version-control.git/213951
> http://thread.gmane.org/gmane.comp.version-control.git/214888
I would again like to express my discomfort about this feature, which is
already listed as "will merge to next". Frankly, I have the feeling
that this feature is being steamrolled in before a community consensus
has been reached and indeed before many valid points raised by other
members of the community have even been addressed. For example:
* I didn't see a response to Peff's convincing arguments that this
should be a client-side feature rather than a server-side feature [1].
* I didn't see an answer to Duy's question [2] about what is different
between the proposed feature and gitnamespaces.
* I didn't see a response to my worries that this feature could be
abused [3].
I also think that the feature is poorly designed. For example:
* Why should a repository have exactly one setting for what refs should
be hidden? Wouldn't it make more sense to allow multiple "views" to be
defined?:
[view "official"]
hiderefs = refs/pull
hiderefs = refs/heads/??/*
[view "pu"]
hiderefs = refs/pull
[view "current"]
hiderefs = refs/tags/releases
with the view perhaps selected via a server-side environment variable?
This would allow multiple views to be published via different URLs but
referring to the same git repository.
* Is it enough to support only reference exclusion (as opposed to
exclusion and inclusion rules)? Is it enough to support only reference
selection by hierarchy (for example, how would you hide contributed
branches from your repo)? Can your configuration scheme be expanded in
a backwards-compatible way if these or other extensions are added later?
* Why should this feature only be available remotely? It would be handy
to clone everything but usually only see some subset of references in my
daily work: "GIT_VIEW=official gitk --all &". Or to hide some remote
branches most of the time without having to remove them from my repo:
[view "brief"]
refs = refs
refs = !refs/remotes
refs = refs/remotes/origin
refs = refs/remotes/my-boss
I think there are still more questions than answers about this feature
and FWIW vote -1 on merging it to next at this time.
Michael
[1] http://article.gmane.org/gmane.comp.version-control.git/214168
[2] http://article.gmane.org/gmane.comp.version-control.git/214070
[3] http://article.gmane.org/gmane.comp.version-control.git/213957
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
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
