matplotlib-devel Mailing List for matplotlib

On 2011年5月27日 09:51:37 -1000, Eric Firing wrote:
[clip]
> Nice--but what exactly is the meaning of "left" and "right"?
When you write
	git checkout this-branch
	git merge other-branch
the left parent of the new merge commit is `this-branch` and
the right one is `other-branch`.
The "commits pulled" just means the commits that are in the DAG of one
parent but not in that of the other.
I just pulled the terminology out from thin air...
> Is it true that if all best practices were followed, there would 
> be no "left to right" commits pulled? 
No: if you have this situation:
 --A-------B main branch
 \
 C----D topic branch 
and merge the topic branch back to the main branch, you will get
merges to "both" directions, with "B" appearing left-to-right.
If you rebase first on B, then you will get only right-to-left, though.
> Is "master" always farthest left?
Not necessarily if things like this have been done:
	git checkout v1.0.x
	git merge upstream/master
	git push upstream HEAD:master
This would give the same result as
 git checkout master
	git merge upstream/v1.0.x
	git push upstream master
but with an inverted order of the parents.
If the merge command is used in the natural way, the "trunk" of the branch
tends to be on the left, and right-to-left merges show what new was merged
to it. But you can manually change this order, and this seems to have
occurred in this case.
	Pauli

On 05/27/2011 08:31 AM, Pauli Virtanen wrote:
> On 2011年5月27日 07:29:15 -1000, Eric Firing wrote:
> [clip]
>> I wouldn't worry about it. It seems likely that other things from
>> master did leak into v1.0.x, but at this point I don't think it matters.
>> v1.0.x and master both build and run (or did last time I checked).
>> The division between the two is somewhat arbitrary anyway. Tracking
>> down and reversing the leakage, if there is any other than the _png.cpp
>> change (which certainly does no harm in v1.0.x), would not be
>> worthwhile.
>
> This probably was already clear to everybody, but you can find
> out what came in the merges:
>
> If no force-pushes have been made, and only one merge was mistaken,
> then there is a single merge commit that brings *all* of
> the mistakenly merged commits into the commit graph.
>
> 1) Locate the merge that pulled lots of stuff, e.g., with
> http://pav.iki.fi/tmp/git-merge-pull-history
> git merge-pull-history -l upstream/v1.0.x|less
>
Pauli,
Nice--but what exactly is the meaning of "left" and "right"? Is it true 
that if all best practices were followed, there would be no "left to 
right" commits pulled? Is "master" always farthest left?
Eric

On 2011年5月27日 07:29:15 -1000, Eric Firing wrote:
[clip]
> I wouldn't worry about it. It seems likely that other things from
> master did leak into v1.0.x, but at this point I don't think it matters.
> v1.0.x and master both build and run (or did last time I checked).
> The division between the two is somewhat arbitrary anyway. Tracking
> down and reversing the leakage, if there is any other than the _png.cpp
> change (which certainly does no harm in v1.0.x), would not be
> worthwhile.
This probably was already clear to everybody, but you can find
out what came in the merges:
If no force-pushes have been made, and only one merge was mistaken,
then there is a single merge commit that brings *all* of
the mistakenly merged commits into the commit graph.
1) Locate the merge that pulled lots of stuff, e.g., with
 http://pav.iki.fi/tmp/git-merge-pull-history
 git merge-pull-history -l upstream/v1.0.x|less
 14406a68c appears to be the first one combining stuff both from
 master and v1.0.x.
 668ef6d8 is a red herring as it shows a merge from already
 contaminated v1.0.x.
2) git show 14406a68c
commit 14406a68c039dc6578730f23955bf34d34008a08
Merge: fdf5fae 132f967
...
3) 
What was pulled in from master to v1.0.x:
git log --oneline fdf5fae ^132f967
git diff 132f967 fdf5fae

On 05/27/2011 05:02 AM, Michael Droettboom wrote:
> On 05/26/2011 03:19 PM, Eric Firing wrote:
>>
>> Mike,
>>
>> I think you did--unintentionally! If you look at the graph with qgit
>> (or presumably any other such tool) in the vicinity of your commits on
>> May 6, you will see that this one
>>
>> a50874b711983cba505ecdb2801c4996eccf3812
>>
>> made v1.0.x branch off of master; the v1.0.x line was broken by the
>> previous commit. To confirm that this break had the effect of
>> propagating the change in _png.cpp into what is now v1.0.x, you can look
>> at the diff between two commits on "v1.0.x", one of which is a bit
>> before the break, the other after:
>>
>> git diff 069c21d 0e6dad src/_png.cpp
>>
>> You will see that the file was changed.
>>
>> Eric
>>
> I'm still not sure what happened there, and even less sure how to
> resolve it. Does this mean we have a bunch of other things from master
> in v1.0.x as well?
Mike,
I wouldn't worry about it. It seems likely that other things from 
master did leak into v1.0.x, but at this point I don't think it matters. 
 v1.0.x and master both build and run (or did last time I checked). 
The division between the two is somewhat arbitrary anyway. Tracking 
down and reversing the leakage, if there is any other than the _png.cpp 
change (which certainly does no harm in v1.0.x), would not be worthwhile.
Better to just move forward, make improvements, and get some good 
releases out.
Eric
>
> Mike
>

On 05/26/2011 03:19 PM, Eric Firing wrote:
>
> Mike,
>
> I think you did--unintentionally! If you look at the graph with qgit
> (or presumably any other such tool) in the vicinity of your commits on
> May 6, you will see that this one
>
> a50874b711983cba505ecdb2801c4996eccf3812
>
> made v1.0.x branch off of master; the v1.0.x line was broken by the
> previous commit. To confirm that this break had the effect of
> propagating the change in _png.cpp into what is now v1.0.x, you can look
> at the diff between two commits on "v1.0.x", one of which is a bit
> before the break, the other after:
>
> git diff 069c21d 0e6dad src/_png.cpp
>
> You will see that the file was changed.
>
> Eric
>
I'm still not sure what happened there, and even less sure how to 
resolve it. Does this mean we have a bunch of other things from master 
in v1.0.x as well?
Mike