Ok,
I'm happy to say that the first cut of my new packed-object-sending thing
seems to work. I have successfully sent updates both locally and over ssh,
and it seems to work fine, although it has some limitations.
The syntax is very simple indeed:
git-send-pack destination
will go to the destination (which can be either a local directory or a
remote ssh one, with the remote destination format currently being _only_
the "machine:path" format), and it will go through all the refs in the
remote destination, compare them with the local ones, and create a pack
that updates from one to the other.
If the pack/unpack sequence is successful, it then updates the refs at the
other end, and is done.
My quick tests were very successful, in the sense that it even performed
really well. But I only tested some small updates.
Anyway, what are the limitations? Here's a few obvious ones:
- the code actually contains support for limiting the refs to be updated
on the remote end, but I don't actually pass the arguments to the
remote git-receive-pack binary yet, so this is currently not
functional. Call me lazy.
- the thing currently refuses to create new refs. Again, this is mainly
just me being lazy: it should be easy to add support for creating a new
branch, it just requires some care to make sure that we take the old
branches into account when generating the pack-file so that we don't
send too many objects over.
- I really hate how "ssh" apparently cannot be told to have alternate
paths. For example, on master.kernel.org, I don't control the setup, so
I can't install my own git binaries anywhere except in my ~/bin
directory, but I also cannot get ssh to accept that that is a valid
path. This one really bums me out, and I think it's an ssh deficiency.
You apparently have to compile in the paths at compile-time into sshd,
and PermitUserEnvironment is disabled by default (not that it even
seems to work for the PATH environment, but that may have been my
testing that didn't re-start sshd).
That just sucks.
- It doesn't update the working directory at the other end. This is fine
for what it's intended for (pushing to a central "raw" git archives),
so this could be considered a feature, but it's worth pointing out.
Only a "pull" will update your working directory, and this pack sending
really is meant to be used in a kind of "push to central archive" way.
- this is also (at least once we've tested it a lot more and added the
code to allow it to create new refs on the remote side) meant to be a
good way to mirror things out, since clearly rsync isn't scaling.
However, I don't know what the rules for acceptable mirroring
approaches are, and it's entirely possible (nay, probable) that an ssh
connection from the "master" ain't it. It would be good to know what
(of any) would be acceptable solutions..
Anyway, please do give it a test. I think I'll use this to sync up to
kernel.org, except I _really_ would want to solve that ssh issue some
other way than hardcoding the /home/torvalds/bin/ path in my local
copies.. If somebody knows a good solution, pls holler.
Linus
|
