Re: Grafts workflow for a "shallow" repository...?
- From
Michael J Gruber <git@drmicha.warpmail.net>
- Date
- Sep 16, 2008, 13:27 UTC
- Message-ID
- <48CFB44F.8060609@drmicha.warpmail.net>
- In-Reply-To
- <20080916080908.GA14272@atjola.homenet>
Björn Steinbrink venit, vidit, dixit 16.09.2008 10:09:
Show 32 quoted lines
> 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.
Michael