On Fri, Jul 18, 2008 at 12:31 PM, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > 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 >
That's what I have been doing, except using "merge" in the master branch. > To generate a series of patches to send somewhere: > > git format-patch --stdout master..my_feature > my_feature.txt OK, so that's how you use format-patch. -Brett _______________________________________________ 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
