Pushing/fetching from/into a shallow-cloned repository

The git-clone manual page, both [1] and my local copy coming with Git for Windows 1.8.1, say about the --depth command-line option:

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

But having done a shallow clone (--depth=1) of one of my repositories, I was able to record a new commit, push it out to a "reference" bare repository and then fetch back to another clone of the same repository just fine. I have then killed my test commit doing a forced push from another clone and subsequently was able to do `git fetch` in my shallow clone just fine.

So I observe pushing/fetching works OK at least for a simple case like this one.

Hence I'd like to ask: if the manual page is wrong or I'm observing some corner case?

On Thu, 18 Apr 2013 13:52:33 +0400 Konstantin Khomoutov <kostix+git@007spb.ru> wrote:

[...]

Oops, by [1] I wanted to refer to this version: https://www.kernel.org/pub/software/scm/git/docs/git-clone.html

From: "Konstantin Khomoutov" <kostix+git@007spb.ru>
Sent: Thursday, April 18, 2013 10:52 AM

The manual is deliberately misleading. The problem is that the depth is a movable feast that depends on how far the branches have progressed. The DAG will be missing the historic merge bases, and in some scenarios can form disconnected runs of commits. The ref negotiation can also be a problem.

The git\Documentation\technical\shallow.txt has some extra details on issues.

Philip

"Philip Oakley" <philipoakley@iee.org> writes:

Yes, it is erring on the safe side.

It was not coded with the case where the gap widens (e.g. either side rewinds the history) in mind as you explained; for simple cases the code just happens to work, but the users are encouraged not to rely on it to be safe than sorry.

On Thu, 18 Apr 2013 15:46:12 -0700 Junio C Hamano <gitster@pobox.com> wrote:

Well, actually my question arouse during the discussion which followed by this SO question [1] where someone asked if it's possible to update just one file in a remote repository without cloning it first (a-la Subversion, that is). While I perfectly understand that Git data model does not support such "server-side commits" I'm able to envision a case when, say, a developer is asked to perform some minor tweak to the code while they're in a situation with no repository clone at hand and only a crappy/costly cellular link available for communication. I think shallow cloning might be a palliative solution to this kind of problem (a one-off clone/edit/commit/push session).

Taking into account what Duy Nguyen said on this topic, it seems that that description of the shallow cloning in the git-clone manual page could supposedly be made somewhat less denying about what could be done using a shallow clone. May be a note that such a setup could be okay for very simple things like clone/edit/push would be just enough?

1. http://stackoverflow.com/q/16077691/720999

On Fri, Apr 19, 2013 at 6:27 AM, Philip Oakley <philipoakley@iee.org> wrote:

With recent improvements in index-pack, I think we can be certain that all gaps are caught. So either it works or it does not. It cannot lead to an incomplete repository. At least for git and smart http transports. So I'm inclined to lift the limitation for these transports. Missing merge bases remains a limitation the user should be aware of, of course. -- Duy