[Python-Dev] git repositories for trunk and py3k

[Brett Cannon]

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.

-Brett