# Fetching a specific commit by commit ID

3 messages from 2014-12-06 to 2014-12-07. Participants: Olivier Croquette, brian m. carlson.
Thread: https://gitlist.dev/t/38129

## Olivier Croquette, 2014-12-06 12:39

Subject: Fetching a specific commit by commit ID
Message-ID: <0EA82B66-7DDD-40A9-BB9C-94D3B1B43DBB@free.fr>
URL: https://gitlist.dev/e/0EA82B66-7DDD-40A9-BB9C-94D3B1B43DBB%40free.fr

```
Hello everyone,

I 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.

If the commit is already available in the repository, I get:

$ git fetch origin 7365b1a9bd45fbf12b09381d5779b607e232a8cd
From repo1
 * branch            7365b1a9bd45fbf12b09381d5779b607e232a8cd -> FETCH_HEAD
$ echo $?
0

If the commit is not in the repository (but it is present in the remote of course), I get:
$ git fetch origin fc907b94f69b9bd710ba55b5522258b722fefb3b
$ echo $?
1


That brings up following questions/remarks:
- the documentation of git-fetch is not entirely correct, commit ids are partially supported, not only refs
- “git fetch origin fc907” should print an error message on STDERR specifying what the problem is
- 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.

Olivier

```

## brian m. carlson, 2014-12-06 15:52

Subject: Re: Fetching a specific commit by commit ID
Message-ID: <20141206155210.GA22146@vauxhall.crustytoothpaste.net>
URL: https://gitlist.dev/e/20141206155210.GA22146%40vauxhall.crustytoothpaste.net
In-Reply-To: <0EA82B66-7DDD-40A9-BB9C-94D3B1B43DBB@free.fr>

```
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

```

## Olivier Croquette, 2014-12-07 10:15

Subject: Re: Fetching a specific commit by commit ID
Message-ID: <F6468265-A6B4-4065-A3F0-3F198421C08F@free.fr>
URL: https://gitlist.dev/e/F6468265-A6B4-4065-A3F0-3F198421C08F%40free.fr
In-Reply-To: <20141206155210.GA22146@vauxhall.crustytoothpaste.net>

```
On 06 Dec 2014, at 16:52, brian m. carlson <sandals@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.

```