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

["Shawn O. Pearce" <spearce@spearce.org>]

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.