git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Franck <vagabon.xyz@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Question on GIT tutorial.
Date: Thu, 17 Nov 2005 23:24:02 -0800	[thread overview]
Message-ID: <7vd5kyo1v1.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <7vlkznt5tc.fsf@assigned-by-dhcp.cox.net> (Junio C. Hamano's message of "Thu, 17 Nov 2005 11:47:27 -0800")

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.

      reply	other threads:[~2005-11-18  7:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-14 10:20 Question on GIT tutorial Franck
2005-11-17 19:47 ` Junio C Hamano
2005-11-18  7:24   ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vd5kyo1v1.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=vagabon.xyz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).