Four hours ago, Stephen Bloch wrote: > > > On Jan 5, 2011, at 8:10 PM, Robby Findler <ro...@eecs.northwestern.edu> wrote: > > > I'd like to move from one machine to another without pushing to > > the main repo. I know one way to do that is to use my own copy but > > it also seems like I should be able to just pick up those changes > > and scp 'em over to some other machine and apply them with git > > format-patch and git am.
Quick note: using patches is not the same -- it means that the target repository will have it's own commit object created rather than the exact same object. > > Anyone do that? Does it seem advisable? (Any hints on how to do > > it?) > > Isn't the "approved" way to do this simply to pull from one machine > to the other? Of course, you would then need to tell it to push > back to the main repo, rather than where it pulled from, and I'm not > sure how to do that. > > Decidedly NOT a git guru.... There's no approval involved here, since doing such things is completely invisible to the rest of the world. In any case, this *is* one option that you (Robby) can use -- you can pull stuff into a git repository from anywhere, including your own provate repositories (that is, you can list an explicit source repository to pull stuff from). You can easily try that -- get two clones of the plt repo in two different directories, then commit something in one, and do a pull from the other and specify the first as the source to pull from. The only question is how convenient the resulting workflow is for you. In your situation, my guess is that the main inconvenience will be ssh access. For example, when you switch from a laptop to a dept server, you'll want to pull changes from the laptop to your dept account -- and this requires that you ssh into the laptop from that account. For cases like this it would be more convenient to push from the laptop to the dept instead -- but git makes it difficult to do that with a non-bare repo (one that has the files checked out), because it won't change those files on the directory you're pushing into[*]. Because pushing is usually more convenient, but pushing to a working repository is bad, the usual solution is to push into a bare repository on the target account, and have another repository there for actual work. So what happens when you want to switch in the above example is: you push from the laptop to the bare repository in your dept account, then (on the dept machine) you pull from that bare repo to the working one. At this point you're implementing the same functionality that the git server provides in the form of user repositories -- so it's really better to use that. So -- is there any reason that you don't want to do that (=> use a private fork of the plt repo)? If it's speed, then I can help you set up a your own bare repository. If you're worried about "wasting" space with such a user repository fork then you shouldn't (the `fork' command creates a clone on the server, and git uses hard links for that which means that the time and space overheads are minimal). And if you're worried about the complications, then I think that you'll find that it's easier than the other solutions (and you get the benefit of avoiding these traps). [*] Actually, if you insist enough, you can allow this, but the target repository will have its tree out of sync with the repository, which is why it's forbidden by default. It's also possible to make add hook scripts in the target repository that will re-sync files after such a push -- but this is something that can easily run into all kinds of subtle problems, which is why it's almost never done. (Look for pages that talk about deploying html content via git pushes -- it's an example of this which is popular enough to have a bunch of descriptions on the web.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev