Merging instructions

Eric Firing <efiring@...229...> writes:

     git pull --ff-only upstream v1.0.x

(This assumes an "upstream" remote pointing to
`git://github.com/matplotlib/matplotlib.git`.) Then merge your pull

By default, however, if you have cloned from
git@...679...:matplotlib/matplotlib.git then instead of "upstream" the
remote will be "origin".

Are you recommending and assuming that we clone *only* from our
individual github forks, and then add the "upstream" remote to point to
the official repo?

I was assuming that, based on the github instructions:

http://help.github.com/fork-a-repo/

But of course there are many ways to do it. We'll have to decide what we
like best and stick to it in the manual; I personally don't have any
strong opinions on what to call the various repositories. Perhaps
"origin" for the central repository and "public" for your own github
repo (as in the public counterpart of your private development repo)?

If everything is fine, push:

     git push git@...679...:matplotlib/matplotlib.git v1.0.x

Can't this be simplified by using "origin" or "upstream" in place of the
url?

Yes, if that's the read-write address. If you cloned from the read-only
address, you can't push to it.

2. the merge has conflicts

I encountered that last night. The conflict was a simple one that will
occur often: the CHANGELOG needed to have the new entry prepended,

Oh, of course. That's going to occur a lot.

5. v1.0.x doesn't merge cleanly into master

What do you mean by this? What is the symptom?

A merge conflict or (probably much less often) a test failure, because
v1.0.x and master have diverged in the relevant part. An example is pull
request #17, which modifies make.osx:

https://github.com/matplotlib/matplotlib/pull/17

But make.osx has changed in master, so while merging this request will
not have a merge conflict (at least with current v1.0.x), merging to
master will. I created another pull request that includes this one and
resolves the merge conflict:

https://github.com/matplotlib/matplotlib/pull/30

So when #17 is merged into v1.0.x, #30 should be merged into master.

···

--
Jouni K. Sepp�nen
http://www.iki.fi/jks

5. v1.0.x doesn't merge cleanly into master

What do you mean by this? What is the symptom?

A merge conflict or (probably much less often) a test failure, because
v1.0.x and master have diverged in the relevant part. An example is pull
request #17, which modifies make.osx:

https://github.com/matplotlib/matplotlib/pull/17

This brings up something that confuses me, together with related questions, and so might be another topic for this part of the docs:

1) How is it that you were able to add commits to a branch of someone else's fork?

2) How should it be decided who merges a pull request, and when?

3) Under what circumstances, if any, should a pull request involving multiple commits be collapsed into a single changeset prior to being merged and pushed?

Eric

···

On 03/07/2011 10:30 AM, Jouni K. Seppänen wrote:

But make.osx has changed in master, so while merging this request will
not have a merge conflict (at least with current v1.0.x), merging to
master will. I created another pull request that includes this one and
resolves the merge conflict:

https://github.com/matplotlib/matplotlib/pull/30

So when #17 is merged into v1.0.x, #30 should be merged into master.