[Python-Dev] git repositories for trunk and py3k
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:
> <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.
More information about the Python-Dev