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

[Dmitry Potapov <dpotapov@gmail.com>]

On Wed, Sep 17, 2008 at 12:02:25AM +0200, Sverre Rabbelier wrote:
> 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