On Apr 27, Stevie Strickland wrote:
> On Apr 27, 2010, at 1:34 PM, Eli Barzilay wrote:
> >
> > 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 [...]
Yes, and I think that this is similar to doing it with branches which
was raised earlier. But I hope to find some way that is simpler than
both of these.
> A perhaps better way is the following: [...]
>
> 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**.
* Generally, that's a good comment.
* IIRC, you can do can do it in one step: git pull --rebase
* Doing a fetch separately from a merge is probably a good idea
anyway, since it lets you catch up without updating files in your
working directory. It might be a part of a way to make things
easier in the dept of "commit only my local changes and avoid a
rebuild".
* In some cases, you might actually want to avoid rebasing -- for
example, if some of your commits leave a tree in a non-working
state, then you might even want to force a merge of a branch. But
it's probably rare.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
