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

From: Shawn O. Pearce <spearce@spearce.org>
Date: Sep 16, 2008, 05:24 UTC
Message-ID: <20080916052425.GA14644@spearce.org>
In-Reply-To: <46a038f90809152209l2230d9e3o442dac1f5047d2bd@mail.gmail.com>

Martin Langhoff <martin.langhoff@gmail.com> wrote:

> Here is my attempt at a "let's publish a shallow repository for branch
> of moodle". Let me show you what I did...

...

>  # 1.7 was a significant release, anything earlier than that
>  # is just not interesting -- even for pickaxe/annotate purposes
>  # so add a graft point right at the branching point.

...

> Is this kind of workflow (or a variation of it) supported? For this to
> work, we should communicate the grafts in some push operations and
> read them in clone ops - and perhaps in fetch too.

Currently the grafts file isn't transferred over any transport protocol as it is considered to be local only to the repository.

For one thing, grafts are a security risk. Any user can graft anything in at any position and log/blame operations will honor the graft, rather than what is stored in the signed commit chain. Its a low risk, but it allows a peer to lie to you and give you something other than what you asked for.

Pushing (or fetching) a graft just seems ugly. You don't want to fetch a graft if you have no grafts because you have the full history. Nor do you want to fetch a graft that might possibly overwrite/replace a graft you already have. You might not want to push all of your available grafts to a remote. Etc.

I think that in this case the best thing to do is give users a shell script that does roughly:

	git init
	echo $BASE >.git/info/grafts
	git remote add -f origin $url
	git checkout -b master origin/master

Sign the script, and let users verify it before executing. You may also want a script to drag in the history behind by removing the graft and fetching $BASE^, but that is hard because your repository already "has" that.

-- 
Shawn.