On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
>
> You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the
> remote one. The example I gave was about locally creating a single
> project repo from a remote multiproject repo.
Ahh.
Ok, try the patch I just sent out, and see if it works for you. It
_should_ allow you to do exactly that
mkdir new-repo
cd new-repo
git init-db
git pull <remote> <onehead>
and now your "master" branch should be initialized to "onehead".
Oh, except I just realized that I forgot to do a "git checkout" in my
patch, so you'd need to add that (or do it by hand, but you really
shouldn't need to, since the checkout is implied by the "pull").
The downside with this is that it does NOT populate your "remotes"
information (like "git clone" would have done), so either we'd need to
teach "git pull" to do that too, or you just have to do it by hand (so
that you then can do the shorthand "git pull" to update in the future).
> On a tangent: why is there no reverse-clone? I have no shell access
> to the machine, so when I created the remote repo, I had to push, and
> ended up putting 1.2 Gb data on the server.
Yeah, you're supposed to "init-db" and "push". Right now, that tends to
unpack everything (which is bad), although that is hopefully getting fixed
(ie the receiving end shouldn't unpack any more if it is recent. Junio?)
> <looks at manpage>
>
> is this send-pack?
"git push" uses send-pack internally, you shouldn't ever need to use it
yourself.
> From UI perspective it would be nice if this could also be done with clone,
>
> git clone . ssh+git://....
The creation of a new archive tends to need special rights (with _real_
ssh access and a shell you could do it, but "ssh+git" really means "git
protocol over a connection that was opened with ssh, but doesn't
necessarily have a real shell at the other end").
So for most protocols, you simply cannot (and shouldn't) do it. Think
about services like the one that Pasky has set up, that allow you to set
up a new git repo - the setup phase really _has_ to be separate (because
you need to set up your keys etc).
So I think the above syntax is actually not a good one, because it cannot
work in the general case. It's much better to get used to setting up a
repo first, and then pushing into it, and just accepting that it's a
two-phase thing.
Also, from a bandwidth standpoint, you can often (although obviously not
always) make the setup start with something that is _closer_ to what you
want to do. So, for example, you'd often do something like:
(a) ssh to central repository
(b) create the new repository by cloning it _locally_ at the central
place from some other repository that is related
(c) then, from your local (non-central) repository, do a "git push --force"
to force your changes (which now only needs the _incremental_ thing).
An example of this is again the "forking" thing that he repos at at
http://git.or.cz/ already supports.
> >And that "git pull" semantic actually means that if you want a _bare_
> >repository, I think "git --bare init-db" + "git --bare fetch" actually
>
> yes, this works. Two remarks:
>
> * it needs
>
> website/master:master
>
> otherwise you still don't have a branch.
Right. In fact, you should probably do
website/master:refs/heads/master
just to make it really explicit.
> * why are objects downloaded twice? If I do
>
> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
>
> it downloads stuff, but I don't get a branch.
A "fetch" by default won't actually generate a local branch unless you
told it to. It just squirrels the end result into the magic FETCH_HEAD
name, so that you can do
# do the fetch
git fetch git://git.sv.gnu.org/lilypond.git web/master
# look at changes
gitk ..FETCH_HEAD
# If you're happy with them, merge them in
git merge "merge new code" HEAD FETCH_HEAD
and you never actually created a real local branch at all.
If you want "git fetch" to fetch _into_ a branch, you need to tell it so,
by using the full "src:dest" format. Otherwise it doesn't know what branch
to fetch it into.
(And, of course, you can define that branch relationship in your remote
configuration, so you don't actually have to say it explicitly every time)
> If I then do
>
> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
>
> it downloads the same stuff again.
Right. So you can either
(a) do it that way to begin with (because you now told it to put the
results in "master", so you never needed to do the second fetch in
the first place)
or
(b) after you did the first fetch (into FETCH_HEAD), you could also have
just decided to do
git update-ref HEAD FETCH_HEAD ""
(where that "" at the end is really not technically necessary, but it
tells "update-ref" that you _only_ want to do this if the old HEAD
was empty/undefined. Without it, "git update-ref" will just
overwrite HEAD without caring what it contained before, so it can be
a dangerous operation!)
See?
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html