threads / discuss / 2493

Question on GIT tutorial.

Subject: Question on GIT tutorial.

## tl;dr

3 messages between Nov 14, 2005 and Nov 18, 2005.

replies: 2people: 2as markdown or json

Franck· Nov 14, 2005, 10:20 UTC · lore
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
Junio C Hamano· Nov 17, 2005, 19:47 UTC · re: Franck · lore

Re: Question on GIT tutorial.

Franck <vagabon.xyz@gmail.com> writes:
Show 12 quoted lines
> 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.

Junio C Hamano· Nov 18, 2005, 07:24 UTC · re: Junio C Hamano · lore

Re: Question on GIT tutorial.

Junio C Hamano <junkio@cox.net> writes:
Show 10 quoted lines
>> """
>> 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.

← back to recent threads