git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Björn SteinbrinkNext: Björn Steinbrink
Message 5 of 9 in “Grafts workflow for a "shallow" repository...?”
  1. Martin LanghoffSep 16, 2008
  2. Shawn O. PearceSep 16, 2008
  3. Junio C HamanoSep 16, 2008
  4. Björn SteinbrinkSep 16, 2008
  5. Michael J GruberSep 16, 2008
  6. Björn SteinbrinkSep 16, 2008
  7. Sverre RabbelierSep 16, 2008
  8. Dmitry PotapovSep 16, 2008
  9. SergioSep 16, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.