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

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2008.09.16 15:27:43 +0200, Michael J Gruber wrote:
> Björn Steinbrink venit, vidit, dixit 16.09.2008 10:09:
> > On 2008.09.15 23:25:10 -0700, Junio C Hamano wrote:
> >> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >>
> >>> 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.
> >>> ...
> >>> 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.
> >> Why not just filter-branch _once at the origin_ and publish the result?
> > 
> > I think the idea was to have a shallow clone starting at a certain
> > point, as opposed to the --depth option, where you cannot specify a
> > starting point, but only the depth of the clone.
> 
> That's what Junio suggests:
> 
> chop the history by introducing an appropriate graft
> make it "permanent" by filter-branching (and remove from info/grafts).
> 
> Now you have a disconnect dag. clone/push/whatever works on the
> "components" given by connected branches.
> 
> Note that in this approach all history after the "chopping point" will
> be rewritten, i.e. get new sha1's.

But shallow clones using --depth don't get alterted hashed. They have
"graft-like" entries in .git/shallow (or whatever it is called) instead.

Assuming that using a shallow clone is worth the hassle (ie. you have to
fetch significantly less data than with a full clone), I can imagine
some use-cases for that, for example bisecting a bug of which you know
that it was introduced after the last release. Just shallow clone the
repo from that version's tag onwards and bisect locally, while still
being able to use the original hash to report the broken version. Or
genrally anything for which you need a recent part of the history and
which requires you to talk about certain commits. The hashes are useful
for that, and filter-branch'ing breaks that.

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.

Björn