Question on GIT tutorial.

Question on GIT tutorial.

[Franck]

Hi,

I have a question about the GIT tutorial. At page 21, there is a
description of "subsystem maintainer" work cycle, I don't understand
why point 3 is needed. This point tells:

"""
Copy over the packed files from "project lead" public repository to
your public repository.
"""

Why is it needed ?

Thanks
--
               Franck

Re: Question on GIT tutorial.

[Junio C Hamano]

Franck <vagabon.xyz@gmail.com> writes:

> Hi,
>
> I have a question about the GIT tutorial. At page 21, there is a
> description of "subsystem maintainer" work cycle, I don't understand
> why point 3 is needed. This point tells:
>
> """
> Copy over the packed files from "project lead" public repository to
> your public repository.
> """
>
> Why is it needed ?

That was a remnant from the days some transports did not
understand objects/info/alternates; I think we do not need that
step anymore.

Re: Question on GIT tutorial.

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

>> """
>> Copy over the packed files from "project lead" public repository to
>> your public repository.
>> """
>>
>> Why is it needed ?
>
> That was a remnant from the days some transports did not
> understand objects/info/alternates; I think we do not need that
> step anymore.

After re-reading that section, I take it back.  What I meant to
say there was this:

   You are the subsystem maintainer, so your tree would have
   many overlapping objects with your project lead.  So in step
   2, you prepare an empty repository first, and then in step
   3., copy the packs from the project lead.  Then pushing into
   that repository in step 4 would prevent the objects you
   inherited from your project lead from getting expanded in
   your public repository.

But these days, there is a more efficient way *if* your public
repository resides on the same machine as the public repository
of your project lead.  First, on the public repository side:

   pub$ export GIT_DIR=/pub/my.git
   pub$ HIS_GIT=/pub/his.git
   pub$ git-init-db
   pub$ echo "$HIS_GIT/objects" >"$GIT_DIR/objects/info/alternates"
   pub$ (cd "$HIS_GIT/refs" && tar - heads tags) |
        (cd "$GIT_DIR/refs" && mkdir j.u.n.k && cd j.u.n.k && tar xf -)

This makes your repository to have the same refs as your
project lead has but under funny names.  Then from your primary
development repository, you push into your public repository:

   home$ git-send-pack --all ssh://pub.repo.xz/pub/my.git/

Thanks to the funny refs you stole from your project lead when
you prepared your public repository, this transfer sends only
objects the project lead does not have, and your refs.  After
this is done, you can get rid of the funny refs you stole from
your project lead:

   pub$ cd "$GIT_DIR/refs" && rm -fr j.u.n.k

If your public repository is not on the same machine as your
project lead's, objects/info/alternates trick cannot be used, so
what we have in the tutorial section still applies.