Re: Grafts workflow for a "shallow" repository...?

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Sep 16, 2008, 23:12 UTC
Message-ID: <20080916231232.GK28210@dpotapov.dyndns.org>
In-Reply-To: <bd6139dc0809161502t121c5aa5la53784bb8ff273a2@mail.gmail.com>

On Wed, Sep 17, 2008 at 12:02:25AM +0200, Sverre Rabbelier wrote:

Show 7 quoted lines

> On Tue, Sep 16, 2008 at 15:50, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> > Maybe instead of providing "pre-shallowed" repos to clone from, that
> > should have been an RFE to support shallow clones starting at a given
> > commit in the DAG? I have no idea whether that's feasible though.
> 
> Would it be like grafts, only the graft is set up by the fetcher,
> instead of the host?

No, the idea is to have it in the $GIT_DIR/shallow format, which differs from grafts in that it cannot add new parents. So, it can only truncate history, while grafts adding new parents can modify history in different ways.

> (E.g., the graft is created on clone, instead of
> -before- the clone, by means of the --depth parameter?) Which means
> the mentioned security risk is not there (what with the fetcher
> setting it up himself).

The important difference between grafts and shallow is that the latter does not allow you to add new parents. So, you cannot modify history but only truncate existing one. So I am not sure about what security risk you are talking about. Obviously, that git blame will attribute all changes that were done before to the earliest downloaded commit. Other than that, I don't think that you can fake anything here. All downloaded history will be correct and that can be verified based on SHA-1.

Also, I believe that the default mode should be to ignore this shallow file on server unless the user specified the corresponding option to make a shallow copy.

BTW, the current implementation of shallow copy has some limitations. See Documentation/technical/shallow.txt for details.

Dmitry