Re: "git-send-pack"
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Jun 30, 2005, 19:49 UTC
- Message-ID
- <Pine.LNX.4.21.0506301403300.30848-100000@iabervon.org>
- In-Reply-To
- <Pine.LNX.4.58.0506301025510.14331@ppc970.osdl.org>
On Thu, 30 Jun 2005, Linus Torvalds wrote:
Show 14 quoted lines
> 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.
Show 5 quoted lines
> - 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.
Show 8 quoted lines
> - 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*