[racket-dev] Git

Four hours ago, Stephen Bloch wrote:
> 
> 
> On Jan 5, 2011, at 8:10 PM, Robby Findler <robby at 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!