[plt-dev] pushes & pulls & building

The story for rebasing isn't quite as clear-cut as I presented if  
you're pushing out of a clone, because you'll also have to fix the  
history on your regular repo via a similar rebase when you update  
that. So I wouldn't suggest it for people until you understand the  
issues involved.



On Apr 27, 2010, at 2:09 PM, Stevie Strickland <sstrickl at ccs.neu.edu>  
wrote:

> 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_________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev