[plt-dev] pushes & pulls & building

On Apr 28, Philippe Meunier wrote:
> Stevie Strickland wrote:
> >On Apr 27, 2010, at 4:14 PM, Robby Findler wrote:
> >> For some context: I was hoping that gits fanciness would allow me to
> >> have some kind of intermediary between the public repository and my
> >> various machines. That is, I imagine something where I can let my
> >> laptop and my machine at home talk to my machine at work so that
> >> changes I make can be visible in all three places without having to
> >> make them public to the whole world.
> >
> >I currently do this.  The way I do this is the following:
> >
> >1) Create a clone of the PLT tree in my usr.  For example,
> >
> >  ssh git.racket-lang.org fork plt usr/sstrickl/plt
> >
> >2) Use that as the origin for clones on my machines.  On each machine, I do:
> >
> >  git clone git.racket-lang.org:usr/sstrickl/plt
> >
> >3) Add a remote for the official PLT repo for convenience in each such repo.
> >
> >  git remote add git-plt git.racket-lang.org:plt
> >
> >4) When I need to pull in changes made by others on the main repo, I do:
> >
> >  git fetch git-plt
> >  git merge git-plt/master
> >  git push
> >
> >which takes the new changes from the main git repo and applies them to my copy.
> 
> So you get new changes from the main repo to your local repo across
> the internet, then push these changes across the internet from your
> local repo to your private copy of the main repo on the main git
> server, and then later you'll sit in front of your laptop computer
> and pull again all the changes across the internet from your private
> copy of the main repo on the main git server to your local repo on
> your laptop.  Do I get this right?

Yes.


> Is there a process that's a bit more network-optimized?

Yes -- you can do this whole story with "your private copy" being
anywhere you want -- including your own server (which is really any
machine that you have ssh access to).


> Like: remotely get the new changes from the main repo on the main
> git server to my private copy of the main repo on the main git
> server,

That's not possible for you to do with git commands, since these
commands only push/pull between two repositories.  I could do it since
I could log on to the server and do it locally there -- so in the
future it might be possible to implement something like this.  (This
is similar to forking with "ssh git-plt fork plt usr/eli/plt" -- it's
a command that you execute through the gateway thing, which is
implemented by running "git clone" on the server -- so it might be
easy to do something like that for pulls and pushes.)


> then simply pull the result to my local repo by doing a 'git pull'
> as usual, then simply pull those changes to my laptop (by doing a
> 'git pull my-local-desktop:path/to/repo master' or some other
> incantation like that)?

This last part is certainly possible now.  Stevie was replying to
Robby who prefers to go through the plt server.


> In fact it looks to me like, rather then going through a private copy
> of the main repo that sits on the main git server, what I should
> really do is have my own local public git server.  Then I can use it
> to synchronize things between machines locally, break any code I want,
> pull new changes from the main repo whenever I want, and only push
> from that server to the main repo when I'm ready.

Exactly -- that's my second "yes" above.  And BTW, this "my own local
public git server" only needs to be "public" enough for you to be able
to ssh to it.  Nothing else is required.  (IOW, the overhead for
setting up a "server" is inexistent if you have some machine with
ssh.)


> In other words, move to a truly distributed system for which git was
> designed rather than trying to shoe-horn git into something that
> looks like svn?

Right -- and you can skip one more aspect of this shoehorning: you
don't even need a separate repository to serve as an intermediate.
Instead, you can do your work completely in local branches (as much as
you want), then push from them to the master branch on the plt server.
The *only* thing that you "lose" here is a remote backup.

As for how much such a backup is needed -- I doubt that it is as
needed as it seems to be in these discussions: there are very few
people who used long term commits, and they're all on the same
department that the server lives at so they get the same backups.  On
the other hand, with svn I *did* have a bunch of changes in random
directories, sometimes just files open in my (almost-)never-ending
emacs -- this kind of parallel work is perfect for local branches that
never need to go out anywhere.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!