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