git questions

Development matplotlib-devel
1

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

2

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
matplotlib download | SourceForge.net
...
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

3

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.

4

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

···

from my development branch, changes from the branch are interleaved with

5

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
matplotlib download | SourceForge.net
...
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
    

6

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
matplotlib download | SourceForge.net
...
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
matplotlib-devel List Signup and Options

7

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
matplotlib download | SourceForge.net
...
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
matplotlib-devel List Signup and Options
    
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

8

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 :wink: 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
matplotlib download | SourceForge.net
...
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
matplotlib-devel List Signup and Options
    
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

9

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 :wink: 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
matplotlib download | SourceForge.net
...
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
matplotlib-devel List Signup and Options
    

10

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

···

On Tue, Jan 6, 2009 at 3:07 PM, Andrew Straw <strawman@...36...> 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.