On Fri, Jul 18, 2008 at 11:57:21AM -0700, Brett Cannon wrote:
> I figured this out. I just did ``git reset --hard``, did the proper
> "fetch;rebase" dance, resolved the conflict, did ``git add`` and then
> continued with the rebase. It all looks fine now.
Doing a fetch followed by a rebase is similar to what "svn up" does
and is what you want in this case. Rebase rewrites patches
(commits) so that they apply to a different version of a tree (they
will get new SHA ids). If you use merge then your patches (commits)
stay unchanged and a new commit object is created that contains the
info required to integrate them with the new tree.
Using merge is also useful in certain cases (e.g. in a distributed
environment, if you have published your changes already and people
have them in their repositories) but the downside is the extra merge
commit object. However, since in this specific case you are always
pushing back to a central repo you should avoid merge.
BTW, the rebase command is very handy if you are maintaing some
change over a longer term. Here's an example workflow:
<start with git checkout>
git checkout -b my_feature # create a private branch
<edit code, commit changes>
git checkout master # back to main branch
<time passes>
git fetch git-svn && git rebase git-svn # update master to latest code
git checkout my_feature # back to private branch
git rebase master # make my changes apply to latest code
To generate a series of patches to send somewhere:
git format-patch --stdout master..my_feature > my_feature.txt
Cheers,
Neil
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
