Recommended steps for a "subsystem maintainer" ?

Hi,

The doc,http://www.kernel.org/pub/software/scm/git/docs/gitcore-tutorial.html at "Working with Others" recommended steps for a "subsystem maintainer". See below. But, I do not understand the step 3. Copy over the packed files from "project lead" public repository to your public repository. The step 1 used git-clone. That means, I got the code including histories as well. Why do I need step 3 to get the packed files? If I really need the packed files, how do I get it? As an example, I need to get the packed files for http://git.denx.de/?p=u-boot.git;a=summary . How can I get the files something like, pack-d5ef1966072c86ef5108ac57525b802581de5d21.idx and pack-d5ef1966072c86ef5108ac57525b802581de5d21.pack ? The snapshot dose not have the packed files. They are all text files.

A recommended work cycle for a "subsystem maintainer" who works on that project and has an own "public repository" goes like this:

1. Prepare your work repository, by git-clone the public repository of the "project lead". The URL used for the initial cloning 
   is stored in the remote.origin.url configuration variable. 

2. Prepare a public repository accessible to others, just like the "project lead" person does. 

3. Copy over the packed files from "project lead" public repository to your public repository, unless the "project lead" repository lives on the same machine as yours. In the latter case, you can use objects/info/alternates file to point at the repository you are borrowing from. 

4. Push into the public repository from your primary repository. Run git-repack, and possibly git-prune if the transport used for pulling from your repository supports packed repositories. 

5. Keep working in your primary repository. Your changes include modifications of your own, patches you receive via e-mails, and merges resulting from pulling the "public" repositories of your "project lead" and possibly your "sub-subsystem maintainers". 

   You can repack this private repository whenever you feel like.

6. Push your changes to your public repository, and ask your "project lead" and possibly your "sub-subsystem maintainers" to pull from it. 

7. Every once in a while, git-repack the public repository. Go back to step 5. and continue working. 

Thank you,

Gary