Git shallow clones and selective branch fetching

Behavior on shallow clones

• git fetch --depth will remove prior revision whereas git clone --depth followed by normal fetch will just start with a shallow clone and stack new commits on top of that. Therefore fetch –depth looks to be potentially destructive although first tests with a local commit seem to be satisfactory.

  Let’s face it, people will be mostly interested in the huge gain of not having the pile of old history.

• git fetch cannot specify a precise revision by SHA1, nor can git clone

  From the Git mailing list:

  No, out of security concerns; imagine you included some proprietary source code by mistake, and undo the damage by forcing a push with a branch that does not have the incriminating code. Usually you do not control the garbage-collection on the server, yet you still do not want other people to fetch “by SHA-1”.

In the recipe

The current implementation of Git support in the recipe starts with an inconditional fetch. Then it is assumed, to detect a branch, that the output of git branch is useful. This way of doing prevents any sparse tactics.

We should probably instead:

• detect SHA references, which can’t be fetched

• fetch what can be fetched

• use a branch indication to allow for sparse fetch/checkout of a precise commit (a very important use-case). Of course, the freeze feature should provide that, meaning that the revisions option should also support it.

  In short, in the absence of tags, the best economy we can make to fix a revision is to limit to the proper branch.

  Worse, branches are just pointers, they aren’t intangible. This means that we should have a retry fetching everything in case the branch does not exist in remote any more, or does not hold the wished commit.