I have successfully used the git mirror to commit changes to the 
maintenance branch.  I've updated the matplotlib developer docs to 
describe how to do it (not that bad really), though it takes a while 
given the v0_98_4 "oops" branch ;)  I have yet to figure out all the 
loop-de-loops required to merge from the maintenance branch to the trunk 
in git and then push that all back to SVN (should be possible, but may 
not play well with svnmerge, anyway).  The good news is that, as always, 
svnmerge still works for that purpose.

Mike

Michael Droettboom wrote:
> Thanks.  These are really helpful pointers.  For me, this is the one 
> missing piece that would help me use git full-time, particularly with 
> the way matplotlib and other projects I work on are laid out in SVN.  So 
> I'm pretty motivated to figure this out.
>
> I'll certainly share any findings in this regard.
>
> Cheers,
> Mike
>
> Andrew Straw wrote:
>   
>> Hi Mike,
>>
>> I have not imported the branches. ( IIRC, this was there were several
>> that weren't MPL but other parts of the repo such as py4science,
>> toolkits and so on).  It may be possible to add just the 0.98.5
>> maintenance branch without the others, but I won't have a chance
>> immediately to play around with that.
>>
>> To add all the branches to your git repo, you might be able to add
>> something like "branches = branches/*:refs/remotes/branches/*" to the
>> [svn-remote "svn"] section of .git/config and re-do "git svn fetch"...
>> This will grab all the branches over all svn history, which will, I
>> think, pull in py4science and toolkits branches... And I guess the
>> download time from svn will be extremely long... In that case it's
>> probably better to rsync from sourceforge's server to a local disk and
>> do the git svn checkout that way making a whole new git repo.
>>
>> It may be worth attempting to talk to some real git/svn gurus at this
>> point about tracking (only one or a couple) svn branches with git
>> branches. So far, I've only dealt with the trunk in my git/svn
>> interoperation experience.
>>
>> -Andrew
>>
>> Michael Droettboom wrote:
>>   
>>     
>>> Thanks.  I've incorporated your docs into the developer documentation.
>>>
>>> My next experiment will be to see if I can track the 0.98.5 maintenance 
>>> branch with git.  SVN tags/* show up as available remote branches, but 
>>> not branches/*, which leaves me a bit stumped?  If you've done this and 
>>> there's a quick answer, let me know, otherwise I'll do a little digging 
>>> to see if it's possible.
>>>
>>> Mike
>>>
>>> Andrew Straw wrote:
>>>     
>>>       
>>>> Hi Michael,
>>>>
>>>> The main issue is that we can't use git "normally" because the main
>>>> history will be kept with svn. Thus, there's going to be a lot of
>>>> history rewriting going on through the rebase command. (These
>>>> complications are obviously not the ideal scenario for git newbies...)
>>>> Rather than answer your questions directly, I'll walk you through how I
>>>> do things. (This is not tried on the MPL svn repo, but some a private
>>>> svn repo. I don't see any fundamental differences, though. So this
>>>> should work.)
>>>>
>>>> (Hopefully this will be cut-and-pasteable ReST, which could go in the
>>>> docs somewhere):
>>>>
>>>> Making a git feature branch and committing to svn trunk
>>>> -------------------------------------------------------
>>>>
>>>> Start with a virgin tree in sync with the svn trunk on the git branch
>>>> "master"::
>>>>
>>>>   git checkout master
>>>>   git svn rebase
>>>>
>>>> To create a new, local branch called "whizbang-branch"::
>>>>
>>>>   git checkout -b whizbang-branch
>>>>
>>>> Do make commits to the local branch::
>>>>
>>>>   # hack on a bunch of files
>>>>   git add bunch of files
>>>>   git commit -m "modified a bunch of files"
>>>>   # repeat this as necessary
>>>>
>>>> Now, go back to the master branch and append the history of your branch
>>>> to the master branch, which will end up as the svn trunk::
>>>>
>>>>   git checkout master
>>>>   git svn rebase # Ensure we have most recent svn
>>>>   git rebase whizbang-branch # Append whizbang changes to master branch
>>>>   git svn dcommit -n # Check that this will apply to svn
>>>>   git svn dcommit # Actually apply to svn
>>>>
>>>> Finally, you may want to continue working on your whizbang-branch, so
>>>> rebase it to the new master::
>>>>
>>>>   git checkout whizbang-branch
>>>>   git rebase master
>>>>
>>>> Michael Droettboom wrote:
>>>>   
>>>>       
>>>>         
>>>>> This is mostly for Andrew Straw, but thought anyone else experimenting
>>>>> with git may be interested.  I'm going through some real newbie pains
>>>>> here, and I don't think what I'm doing is all that advanced.
>>>>>
>>>>> So, I've had a local git repository cloned from github (as per Andrew's
>>>>> instructions), made a branch, started hacking, all is well.  Now, I
>>>>> would like to update my master branch from SVN to get some of the recent
>>>>> changes others have been making.
>>>>>
>>>>> Following the instructions in the FAQ,
>>>>>
>>>>>  git svn rebase
>>>>>
>>>>> actually results in a number of conflicts in files I didn't touch.  I
>>>>> shouldn't have to resolve this conflicts, right?  'git status' shows no
>>>>> local changes, nothing staged -- nothing that should conflict.
>>>>>
>>>>> It turns out, if I do
>>>>>
>>>>>   git pull
>>>>>
>>>>> then,
>>>>>
>>>>>   git svn rebase
>>>>>
>>>>> all is well.
>>>>>
>>>>> Any idea why?  Should I add that to the instructions in the FAQ?
>>>>>
>>>>> Now, here's where I'm really stumped.  I finished my experimental
>>>>> branch, and I would like to commit it back to SVN.
>>>>>
>>>>> This is what I did, with comments preceded by '#'
>>>>>
>>>>> # Go back to the master branch
>>>>>     
>>>>>         
>>>>>           
>>>>>> git checkout master
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> # Merge in experimental
>>>>>     
>>>>>         
>>>>>           
>>>>>> git merge experimental
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> # Ok -- looks good: experimental new feature is integrated, there were
>>>>> no conflicts
>>>>> # However...
>>>>>     
>>>>>         
>>>>>           
>>>>>> git svn dcommit
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> Committing to
>>>>> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
>>>>> ...
>>>>> Merge conflict during commit: File or directory
>>>>> 'doc/users/whats_new.rst' is out of date; try updating: resource out of
>>>>> date; try updating at /home/mdroe/usr/libexec/git-core//git-svn line 467
>>>>> # 1) I didn't change that file, why should I care
>>>>> # 2) I don't know who to update it
>>>>>     
>>>>>         
>>>>>           
>>>>>> git pull
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> Already up-to-date.
>>>>>     
>>>>>         
>>>>>           
>>>>>> git svn rebase
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> First, rewinding head to replay your work on top of it...
>>>>> Applying: more doc adds
>>>>> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
>>>>> whitespace.
>>>>> a lot of new features and bug-fixes. warning: 1 line adds whitespace
>>>>> errors.
>>>>> Applying: added some docs for linestyles and markers
>>>>> Applying: Remove trailing whitespace.
>>>>> Applying: figure/subplot and font_manager bugfixes
>>>>> Applying: added support for xlwt in exceltools
>>>>> Applying: fixed a typo in whats_new_98_4_legend.py
>>>>> Applying: fixed typo in Line2D.set_marker doc.
>>>>> Applying: /matplotlib/__init__.py: catch OSError when calling subprocess.
>>>>> Applying: more doc adds
>>>>> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
>>>>> whitespace.
>>>>> a lot of new features and bug-fixes. error: patch failed:
>>>>> doc/users/whats_new.rst:10
>>>>> error: doc/users/whats_new.rst: patch does not apply
>>>>> Using index info to reconstruct a base tree...
>>>>> <stdin>:14: trailing whitespace.
>>>>> a lot of new features and bug-fixes. warning: 1 line adds whitespace
>>>>> errors.
>>>>> Falling back to patching base and 3-way merge...
>>>>> No changes -- Patch already applied.
>>>>> Applying: added some docs for linestyles and markers
>>>>> error: patch failed: doc/devel/coding_guide.rst:62
>>>>> error: doc/devel/coding_guide.rst: patch does not apply
>>>>> error: patch failed: doc/matplotlibrc:43
>>>>> error: doc/matplotlibrc: patch does not apply
>>>>> error: patch failed: doc/pyplots/whats_new_98_4_legend.py:4
>>>>> error: doc/pyplots/whats_new_98_4_legend.py: patch does not apply
>>>>> error: patch failed: lib/matplotlib/lines.py:313
>>>>> error: lib/matplotlib/lines.py: patch does not apply
>>>>> Using index info to reconstruct a base tree...
>>>>> Falling back to patching base and 3-way merge...
>>>>> Auto-merged doc/pyplots/whats_new_98_4_legend.py
>>>>> CONFLICT (content): Merge conflict in doc/pyplots/whats_new_98_4_legend.py
>>>>> Auto-merged lib/matplotlib/lines.py
>>>>> Failed to merge in the changes.
>>>>> Patch failed at 0010.
>>>>>
>>>>> When you have resolved this problem run "git rebase --continue".
>>>>> If you would prefer to skip this patch, instead run "git rebase --skip".
>>>>> To restore the original branch and stop rebasing run "git rebase --abort".
>>>>>
>>>>> rebase refs/remotes/trunk: command returned error: 1
>>>>> # Ok, I'm back to merging files that don't conflict with my changes! # I
>>>>> shouldn't have to do that, right?
>>>>> # And FYI:
>>>>>     
>>>>>         
>>>>>           
>>>>>> git status
>>>>>>       
>>>>>>           
>>>>>>             
>>>>> doc/pyplots/whats_new_98_4_legend.py: needs merge
>>>>> # Not currently on any branch.
>>>>> # Changes to be committed:
>>>>> #   (use "git reset HEAD <file>..." to unstage)
>>>>> #
>>>>> #    modified:   lib/matplotlib/lines.py
>>>>> #
>>>>> # Changed but not updated:
>>>>> #   (use "git add <file>..." to update what will be committed)
>>>>> #
>>>>> #    unmerged:   doc/pyplots/whats_new_98_4_legend.py
>>>>> #
>>>>> # Untracked files:
>>>>> #   (use "git add <file>..." to include in what will be committed)
>>>>> #
>>>>> #    lib/matplotlib/mpl-data/matplotlib.conf
>>>>> #    lib/matplotlib/mpl-data/matplotlibrc
>>>>> #    setupext.pyc
>>>>> #    src/backend_agg.cpp~
>>>>>
>>>>> Now I feel stuck.  How do I "undo" the merge from experimental to master?
>>>>>
>>>>> Sorry if these are obvious questions, but I think I've followed the
>>>>> git-svn instructions -- I must have made a mistake somewhere along the
>>>>> way, but I'm not sure how to debug and/or fix it.
>>>>>
>>>>> Mike
>>>>>     
>>>>>         
>>>>>           
>>>>   
>>>>       
>>>>         
>>> ------------------------------------------------------------------------------
>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
>>> The future of the web can't happen without you.  Join us at MIX09 to help
>>> pave the way to the Next Web now. Learn more and register at
>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>     
>>>       
>>   
>>     
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to