[plt-dev] pushes & pulls & building

On Apr 27, 2010, at 1:34 PM, Eli Barzilay wrote:
> On Apr 27, Jay McCarthy wrote:
>> On Tue, Apr 27, 2010 at 11:25 AM, Robby Findler
>> <robby at eecs.northwestern.edu> wrote:
>>> In order to do a push this morning, I had to do a pull. Which
>>> suggested that I should probably rebuild; I started this process
>>> at 9:30 this morning (it is now 12:30) and I am only just started
>>> on rendering the docs (my changes involve changes to the docs). It
>>> is taking so long because there have been pushes since I pulled
>>> and those pushes required long rebuild times; well, that and my
>>> machine is slow.
>>> 
>>> So, this doesn't seem feasible. What do others do?
>> 
>> This is exactly what I complained about before. Before Git, I would
>> update to the HEAD whenever I observed a cool commit or needed to
>> make a big change, but otherwise would be a few weeks behind. Now, I
>> upgrade every morning to be on the cusp. It is a little annoying,
>> but I've dealt.
> 
> You could do something similar -- updating only before you push,
> without a global rebuild like the one Robby is stuck in.  It won't be
> as robust as making a build, but this is exactly what you'd get when
> you commit a change to your directory and ignore changes around you.
> 
> In any case, I think that it should be possible to get something
> similar as in svn, but I didn't get to write about it yet.

It seems easy enough.  I believe what you'd want to do is just

1) Clone your local repo to another local repo
   git clone /path/to/local/clone /path/to/new/clone
2) In the new repo, pull from git:plt
   cd /path/to/new/clone
   git pull git:plt master
3) Push to git:plt
   git push git:plt master
4) Throw away the new local repo
   rm -rf /path/to/new/clone

A perhaps better way is the following:
  git clone /path/to/local/clone /path/to/new/clone
  cd /path/to/new/clone
  *git remote add git-plt git:plt
  git fetch git-plt
  git rebase git-plt/master
  git push git-plt master
  rm -rf /path/to/new/clone

The changed/additional steps are rebasing so that the commits you're adding don't cause spurious three-way merging, especially for changes that are independent of the other, unincorporated changes on master.  This is useful even if you're doing it in your original repository and not doing the cloning step above.  That is, consider a fetch/rebase pattern instead of pull if all your changes are only in your local repository**.

If the commits aren't independent, but conflict, then you'll need to resolve the conflicts.  This is true for both rebasing and merging via pull, though, so it's not necessarily more onerous.

* I'm pretty sure there's not a way to do a rebase with just a URL instead of via a remote branch, but if there is, someone can mention it.

** This is likely the case for most people reading this.  However, if you're keeping your own clone on a public server somewhere or in your usr/ space and pushing your changes to that, either for coordination with others or for coordination between your own machines, then rebasing might be more difficult.

Stevie