On Thu, 30 Jun 2005, Linus Torvalds wrote:
> Anyway, what are the limitations? Here's a few obvious ones:
>
> - 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.
The easiest thing might be to have a centrally-installed wrapper script
that could run programs installed in your home directory. E.g., if
"git" had a "source ~/.git-env" at the beginning, and your ~/.git-env
fixed your PATH, then "git receive-pack ARGS" should work, for a generic
centrally installed git and special stuff in your home directory.
> - 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.
I thought only "resolve" (as part of "fetch") updated your working
directory, so this is completely consistant.
> - 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..
The right solution probably involves getting each pack file you push to
the mirrors as well as to the master. They'll probably update no less
frequently than you push, and they should go through a series of states
which matches the master, so it's not necessary to have anything smart on
master sending them, and they only have to unpack the files they get (and
update the refs afterward). That should make the cross-system trust
requirements relatively minimal; the mirror can fetch things from master,
and neither side has to allow the other to specify a command line.
-Daniel
*This .sig left intentionally blank*
|
