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 ------------------------------------------------------------------------------ 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
