On Sat, Dec 06, 2014 at 01:39:12PM +0100, Olivier Croquette wrote: > That brings up following questions/remarks: > - the documentation of git-fetch is not entirely correct, commit ids > are partially supported, not only refs
This isn't completely true. What you're seeing here is that git fetch performs a negotiation to find out what each side has. As a consequence, if git does not need to fetch the item in question because it already has it, git fetch succeeds. The two sides essentially never get to the point where they have to determine whether the behavior is allowed. > - 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. It does in some cases if the remote supports this. See the uploadarchive and uploadpack groups in git-config(1). However, you can still only access existing branches and tags. 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. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
