[Python-Dev] git repositories for trunk and py3k (original) (raw)

Brett Cannon brett at python.org
Fri Jul 18 21:34:24 CEST 2008

On Fri, Jul 18, 2008 at 12:31 PM, Neil Schemenauer <nas at arctrix.com> 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: git checkout -b myfeature # create a private branch <edit code, commit changes> git checkout master # back to main branch git fetch git-svn && git rebase git-svn # update master to latest code git checkout myfeature # 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..myfeature > myfeature.txt

OK, so that's how you use format-patch.

-Brett

More information about the Python-Dev mailing list