Pushing/fetching from/into a shallow-cloned repository

Pushing/fetching from/into a shallow-cloned repository

[Konstantin Khomoutov]

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?

Re: Pushing/fetching from/into a shallow-cloned repository

[Konstantin Khomoutov]

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

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

[...]

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

Re: Pushing/fetching from/into a shallow-cloned repository

[Philip Oakley]

From: "Konstantin Khomoutov" <kostix+git@007spb.ru>
Sent: Thursday, April 18, 2013 10:52 AM
> 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?
> --
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

Re: Pushing/fetching from/into a shallow-cloned repository

[Junio C Hamano]

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

>> 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?
>> --
> The manual is deliberately misleading.

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.

Re: Pushing/fetching from/into a shallow-cloned repository

[Konstantin Khomoutov]

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

> "Philip Oakley" <philipoakley@iee.org> writes:
> 
> >> 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?
> >> --
> > The manual is deliberately misleading.
> 
> 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.

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

Re: Pushing/fetching from/into a shallow-cloned repository

[Duy Nguyen]

On Fri, Apr 19, 2013 at 6:27 AM, Philip Oakley <philipoakley@iee.org> wrote:
> From: "Konstantin Khomoutov" <kostix+git@007spb.ru>
>> 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?
>> --
>
> 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.

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