Why can't I push from a shallow clone?

Question

The git clone --depth command option says

--depth  
Create a shallow clone with a history truncated to the specified number of revisions. 
A shallow repository has a number of limitations 
(you cannot clone or fetch from it, nor push from nor into it),
 but is adequate if you are only interested in the recent history of a large project with a long history,
 and would want to send in fixes as patches.

Why do shallow clones have this limitation? Why is it a patches only workflow?

For some project workflows I need to pass just the latest commit from a single branch to a coder, and then have them be able to push their (fast forward) developments to the main server. This partly for security, IP protection and repo size, and partly to reduce the confusion that a big repo would bring to a naive coder. Is there a git workflow that allows this?

Update: Based on Karl Bielefeldt's answer the git checkout --orphan should be the right answer. But one still needs to 'clone' that branch alone to the new user, and be able to push it effectively.

The man page states:

git checkout [-q] [-f] [-m] [[-b|-B|--orphan] ] [] --orphan

Create a new orphan branch, named , started from and switch to it. The first commit made on this new branch will have no parents and it will be the root of a new history totally disconnected from all the other branches and commits.

The index and the working tree are adjusted as if you had previously run git checkout . This allows you to start a new history that records a set of paths similar to by easily running git commit -a to make the root commit.

This can be useful when you want to publish the tree from a commit without exposing its full history. You might want to do this to publish an open source branch of a project whose current tree is "clean", but whose full history contains proprietary or otherwise encumbered bits of code.

If you want to start a disconnected history that records a set of paths that is totally different from the one of , then you should clear the index and the working tree right after creating the orphan branch by running git rm -rf . from the top level of the working tree. Afterwards you will be ready to prepare your new files, repopulating the working tree, by copying them from elsewhere, extracting a tarball, etc.

VonC's link to Junio's comments is interesting. I think the manual should provide the guidance in this case, and allow the right command [e.g. clone --options] to extract just the relevant part of the repo. Obviously the probability of push success is increased by having a few linked commits and SHA1s at the bottom of the history that will lock down the repo matching.

Update Git 1.9.0 : release notes 14 Feb '14.

"Fetching from a shallowly-cloned repository used to be forbidden, primarily because the codepaths involved were not carefully vetted and we did not bother supporting such usage. This release attempts to allow object transfer out of a shallowly-cloned repository in a more controlled way (i.e. the receiver becomes a shallow repository with a truncated history)."

This is good news for the shallow cloners. Next - Narrow clones possibly.

user_4411491 · Answer

I found a workaround using git bundles.

This solution will replicate the exact same commits to the other repository like "git push" would do, and will not require rebasing or result in a changed commit ID.

It requires shell-access (such as ssh) to the target host, unfortunately.

I will show the solution by example.

First we need to get a shallow clone for demonstration purposes.

Lets fetch the single commit release v0.5.0.0 from https://github.com/skarnet/s6-rc into a new repository as a shallow clone.

I will use shell variables in my examples rather than including the example settings directly within the commands, because this will allow you to copy/paste the instruction from this posting directly into your shell, after setting the variables to different values which apply to your situation.

Therefore, feel free to replace the following variable assigmnents by using a different URL and release.

In the case of our example, the shallow clone can be created with:

$ url=https://github.com/skarnet/s6-rc
$ rel=v0.5.0.0
$ git init ${url##*/} && cd ${url##*/}
$ git pull --depth=1 "$url" $rel:master

This will create a "s6-src" (when using the above variable values) subdirectory containing the new clone.

Now that we have our shallow clone containing only a single commit with all its parent history missing in the local repository, we bundle this single commit into a git bundle file:

$ b=$rel.gbnd
$ git bundle create $b HEAD

This will create file v0.5.0.0.gbnd making use of the shell variables set before.

Now you have to copy this file to the target machine where you would normally like to push to. (Only that git push refuses to push from shallow clones and will therefore not work, at least not using older git versions.)

On the target host, do the following in order to create a new repository as a subdirectory, containing the same commit as bundled before:

$ url=https://github.com/skarnet/s6-rc
$ rel=v0.5.0.0
$ git init ${url##*/} && cd ${url##*/}
$ c=`git bundle unbundle $b | cut -d " " -f 1`; echo "$c"
$ git tag $rel $c # optional: create a tag for the imported commit.
$ git reset --hard $c
$ git fetch --depth=1 .

Note that you should set the variables to the same values as you did on the host from which the bundle was copied.

Also note that you can omit the "git init" it the repository already exists.

That's it!

However, the latter instructions only apply for regular checkouts.

Maybe you want to import a shallow clone bundle into a "bare" repository.

In this case, do the following instead:

$ url=https://github.com/skarnet/s6-rc
$ rel=v0.5.0.0
$ cd ${url##*/}.git
$ c=`git bundle unbundle $b | cut -d " " -f 1`; echo "$c"
$ git tag $rel $c
$ git fetch --depth=1 . $rel

Why can't I push from a shallow clone?

3 Answers