On 06 Dec 2014, at 16:52, brian m. carlson <sand...@crustytoothpaste.net> wrote:
>> - more interestingly: is there any reason why git fetch should not >> support fetching by commit id? There are real world use cases where >> this can be very useful, for instance when references on the remote >> have been overwritten or deleted. > > The reason this isn't supported in the general case is because one might > want to restrict access to certain branches. For example, an open > source project might want to embargo some security fixes that are in the > repository. Allowing a user to specify an arbitrary ID would permit > someone to circumvent those access controls. Shouldn’t these checks be implemented in the layers above, eg. in gitolite, gitosis, gerrit… ? Having it in git itself makes it impossible in all cases, even for projects/repositories with no ref-specific read restrictions (the vast majority of projects, I would guess). It seems pretty straightforward to support access control in these layers. If a commit id is provided, go through all references of the repository, if one is found that is a child of the given commit, and the user has access to the ref, then it’s ok to fetch the commit. Of course it’s an expensive operation, but it’s is rarely required. -- 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
