{"thread":{"id":"38129","subject":"Fetching a specific commit by commit ID","startedAt":"2014-12-06T12:39:12Z","lastAt":"2014-12-07T10:15:10Z","messageCount":3,"participants":["Olivier Croquette","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"253241","messageId":"0EA82B66-7DDD-40A9-BB9C-94D3B1B43DBB@free.fr","threadId":"38129","inReplyTo":null,"subject":"Fetching a specific commit by commit ID","fromName":"Olivier Croquette","fromEmail":"ocroquette@free.fr","sentAt":"2014-12-06T12:39:12Z","receivedAt":"2014-12-06T12:39:12Z","isPatch":false,"sender":{"key":"ocroquette@free.fr","avatar":null},"body":"Hello everyone,\n\nI am trying to fetch a commit using a commit ID instead of a reference. According to the documentation of git-fetch, this is not supported, but I found out that this is not entirely true.\n\nIf the commit is already available in the repository, I get:\n\n$ git fetch origin 7365b1a9bd45fbf12b09381d5779b607e232a8cd\nFrom repo1\n * branch            7365b1a9bd45fbf12b09381d5779b607e232a8cd -> FETCH_HEAD\n$ echo $?\n0\n\nIf the commit is not in the repository (but it is present in the remote of course), I get:\n$ git fetch origin fc907b94f69b9bd710ba55b5522258b722fefb3b\n$ echo $?\n1\n\n\nThat brings up following questions/remarks:\n- the documentation of git-fetch is not entirely correct, commit ids are partially supported, not only refs\n- “git fetch origin fc907” should print an error message on STDERR specifying what the problem is\n- 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.\n\nOlivier\n"},{"id":"253247","messageId":"20141206155210.GA22146@vauxhall.crustytoothpaste.net","threadId":"38129","inReplyTo":"0EA82B66-7DDD-40A9-BB9C-94D3B1B43DBB@free.fr","subject":"Re: Fetching a specific commit by commit ID","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-12-06T15:52:10Z","receivedAt":"2014-12-06T15:52:10Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sat, Dec 06, 2014 at 01:39:12PM +0100, Olivier Croquette wrote:\n> That brings up following questions/remarks:\n> - the documentation of git-fetch is not entirely correct, commit ids\n>   are partially supported, not only refs\n\nThis isn't completely true.  What you're seeing here is that git fetch\nperforms a negotiation to find out what each side has.  As a\nconsequence, if git does not need to fetch the item in question because\nit already has it, git fetch succeeds.  The two sides essentially never\nget to the point where they have to determine whether the behavior is\nallowed.\n\n> - more interestingly: is there any reason why git fetch should not\n>   support fetching by commit id? There are real world use cases where\n>   this can be very useful, for instance when references on the remote\n>   have been overwritten or deleted.\n\nIt does in some cases if the remote supports this.  See the\nuploadarchive and uploadpack groups in git-config(1).  However, you can\nstill only access existing branches and tags.\n\nThe reason this isn't supported in the general case is because one might\nwant to restrict access to certain branches.  For example, an open\nsource project might want to embargo some security fixes that are in the\nrepository.  Allowing a user to specify an arbitrary ID would permit\nsomeone to circumvent those access controls.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"253276","messageId":"F6468265-A6B4-4065-A3F0-3F198421C08F@free.fr","threadId":"38129","inReplyTo":"20141206155210.GA22146@vauxhall.crustytoothpaste.net","subject":"Re: Fetching a specific commit by commit ID","fromName":"Olivier Croquette","fromEmail":"ocroquette@free.fr","sentAt":"2014-12-07T10:15:10Z","receivedAt":"2014-12-07T10:15:10Z","isPatch":false,"sender":{"key":"ocroquette@free.fr","avatar":null},"body":"On 06 Dec 2014, at 16:52, brian m. carlson <sandals@crustytoothpaste.net> wrote:\n\n>> - more interestingly: is there any reason why git fetch should not\n>>  support fetching by commit id? There are real world use cases where\n>>  this can be very useful, for instance when references on the remote\n>>  have been overwritten or deleted.\n> \n> The reason this isn't supported in the general case is because one might\n> want to restrict access to certain branches.  For example, an open\n> source project might want to embargo some security fixes that are in the\n> repository.  Allowing a user to specify an arbitrary ID would permit\n> someone to circumvent those access controls.\n\nShouldn’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).\n\nIt 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.\n"}]}