Recommended steps for a "subsystem maintainer" ?

Recommended steps for a "subsystem maintainer" ?

[Gary Yang]

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





      

Re: Recommended steps for a "subsystem maintainer" ?

[Michael J Gruber]

Gary Yang venit, vidit, dixit 19.11.2008 21:47:
> 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?

Step 1 sets up your private development repo. Step 3 talks about your
public repo.

It's recommended you get the original packs because differently abled
protocols like http cannot repack on the fly. That is, if people pull
via http from upstream and your public repo they might have to download
two different packs for (almost) the same objects.

> 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.

Snapshots are about files, i.e. contents. They've got nothing to do with
packs. May I suggest reading of both parts of the git tutotorial, as
well as the user manual, in order to clarify some concepts? This would
be an ideal first step before thinking about becoming a subsystem
maintainer.

You can get the original upstream packs by copying them (if you have
shell access) or simply by cloning via http. Store them in
.git/objects/pack of your public repo before you push anything into it,
and don't run "repack -adf" there (repack is OK).

Michael