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
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
Andrew Straw wrote: I realize I may have ignored an important question. > Michael Droettboom wrote: >> Now I feel stuck. How do I "undo" the merge from experimental to master? To do that, I actually delete the master branch with "git branch -D master" and then re-create a new one with "git checkout -b master 028a0df8" (where I've identified commit 028a0df8 as where I want the new master to be). Note that before deleting the master branch, it's probably wise to create a branch, which will probably be deleted momentarily, as a reference to this location in case you need to get back to it. Do so with "git checkout -b tmp/old-master". When everything is done, use "git branch -D tmp/old-master" to delete it.
Andrew Straw wrote: > Andrew Straw wrote: > > I realize I may have ignored an important question. > > >> Michael Droettboom wrote: >> > > >>> Now I feel stuck. How do I "undo" the merge from experimental to master? >>> > > To do that, I actually delete the master branch with "git branch -D > master" and then re-create a new one with "git checkout -b master > 028a0df8" (where I've identified commit 028a0df8 as where I want the new > master to be). > Thanks for the suggestion. Because I "merged", rather than "rebased" from my development branch, changes from the branch are interleaved with changes from SVN, so it's not clear to me how to remove only the changes that were brought in from the merge. But that might also be the root cause of the problem I'm having. I tried going back to the first SVN change prior to anything on my branch, the "git svn rebase", but that didn't solve the issue -- it still requires me to merge changes I know nothing about. I think I'll follow your suggestion of "rebasing" development branches -- I can see how that's superior to "merge" anyway, since it will hide all my work/mistakes from the central SVN repository. I'm going to declare bankruptcy at re-clone the whole repository and see if things work better. Wish I understood how I painted myself in this corner in the first place, but maybe I'll notice it next time around. Mike
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 >> > >
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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
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 >>> Mat...@li... >>> 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
Hi Mike, This sounds like good news. I am swamped right now, but I hope to get the git mirror on github up-to-date early next week when work is a little less busy. John (or any developer with SF admin capabilities), if we could set up some kind of auto-notification on SVN commits, I could possibly set up a script to update the git repo. The thing I've seen so far is to go to the Sourceforge project page and under "Admin" selection "Subversion" then at the bottom in the "Hooks" section, change the entry to "ciabot_svn.py - Send commit stats to cia.navi.cx". If you could do that, from there I will attempt to take things to auto-update the git mirror. -Andrew Michael Droettboom wrote: > 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 >>>> Mat...@li... >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>> >>>> >>> >>> >> >
On Tue, Jan 6, 2009 at 3:07 PM, Andrew Straw <str...@as...> wrote: > Hi Mike, This sounds like good news. I am swamped right now, but I hope > to get the git mirror on github up-to-date early next week when work is > a little less busy. > > John (or any developer with SF admin capabilities), if we could set up > some kind of auto-notification on SVN commits, I could possibly set up a > script to update the git repo. The thing I've seen so far is to go to > the Sourceforge project page and under "Admin" selection "Subversion" > then at the bottom in the "Hooks" section, change the entry to > "ciabot_svn.py - Send commit stats to cia.navi.cx". If you could do > that, from there I will attempt to take things to auto-update the git > mirror. I think you should have the permissions to do this Andrew so give it a shot and let me know if you encounter any problems. BTW, hexbin has been really useful to me -- I made a couple of enhancements (adding the marginal distributions, suppressing cells where mincnt < some threshold) so check them out with your use cases. JDH
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 >> Mat...@li... >> 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