matplotlib-devel Mailing List for matplotlib

On 05/18/2011 11:45 AM, Darren Dale wrote:
>>
>> I suspect the anomalies have not resulted from forced pushes, but from
>> local pulls and merges followed by innocuous pushes. So the key is
>> understanding how to ensure one's local branches have the desired
>> history before pushing to github. (And making sure one is pushing from
>> the correct source to the correct destination. Trying first with
>> --dry-run can help.)
>
> Before pushing, I also recommend inspecting the history graph, either
> with "gitk --all" or "git log --oneline --graph --all". I try to
> remember to make sure the history graph looks the way I expect it
> should before I push anywhere.
QGit is another alternative.
Eric

On Wed, May 18, 2011 at 3:22 PM, Eric Firing <ef...@ha...> wrote:
> On 05/18/2011 08:47 AM, Benjamin Root wrote:
>>
>>
>> On Tue, May 17, 2011 at 9:07 PM, Gerald Storer <gd...@mr...
>> <mailto:gd...@mr...>> wrote:
>>
>>   On 18/05/2011 5:14 AM, Eric Firing wrote:
>>   > 3) We don't have to always push sets of changes from an original pull
>>   > request to upstream; they can be consolidated using any of a
>>   variety of
>>   > methods to form a new local feature branch with the same net
>>   effect but
>>   > fewer commits (maybe only one), and then that can be merged (which
>>   > should be fast-forward, no merge commit) and pushed to upstream.
>>    This
>>   > takes a little more work than simply accepting (merging) a pull
>>   request
>>   > as-is, but in many cases it may be worth it because it can yield a
>>   > cleaner history. Similarly, if someone is developing a feature
>>   branch
>>   > on github, and the net effect is correct but the branch has
>>   intermediate
>>   > commits that distract from the net result, then a good practice
>>   would be
>>   > for that person to consolidate the changes into a new feature branch
>>   > with a cleaner history, close the pull request on the old one and
>>   open a
>>   > new request for the polished branch.
>>   >
>>   I believe this script more or less automates the process:
>>   https://github.com/jeresig/pulley
>>
>>   Gerald.
>>
>>
>> Don't know if this was a mistake or not, but I see that commit e7f1e83
>> (the one to fix a clipping issue when a patch's line width is 1 but
>> there is no color) seems to have been merged back into itself...
>> somehow... in commit 0c886b8. I have seen things like this before, and
>> I never quite understood how they happen. Plus, do we want to get that
>> patch merged down to master?
>
> Yes, it needs to get merged to master; but no, I don't think anything
> was "merged back into itself"; instead, it is just a case where a
> fast-forward with no merge commit would have left a simpler history--one
> commit instead of two.
>
> Merging from v1.0.x to master doesn't have to be done after every change
> to v1.0.x, but it shouldn't be left undone for very long. A few days
> ago I wasted a chunk of time thrashing around on master because of a bug
> that had been fixed on 1.0.x but was not yet merged into master--and I
> had not thought to check their relative states. The bug had actually
> been introduced to master via a recent change merged from 1.0.x.
>
> We are experiencing some bumps on the git/github learning curve, but not
> nearly enough to make me pine for svn.
>
>>
>> I think we definitely need to see what sort of controls we can put in
>> place to prevent mix-ups in the future. One thing I did like about SVN
>> was that it was next to impossible to change the history. Meanwhile,
>> with git, it becomes possible. Is there some way we can disallow forced
>> pushes, maybe? Just a thought...
>>
>
> I suspect the anomalies have not resulted from forced pushes, but from
> local pulls and merges followed by innocuous pushes. So the key is
> understanding how to ensure one's local branches have the desired
> history before pushing to github. (And making sure one is pushing from
> the correct source to the correct destination. Trying first with
> --dry-run can help.)
Before pushing, I also recommend inspecting the history graph, either
with "gitk --all" or "git log --oneline --graph --all". I try to
remember to make sure the history graph looks the way I expect it
should before I push anywhere.

On 05/18/2011 08:47 AM, Benjamin Root wrote:
>
>
> On Tue, May 17, 2011 at 9:07 PM, Gerald Storer <gd...@mr...
> <mailto:gd...@mr...>> wrote:
>
> On 18/05/2011 5:14 AM, Eric Firing wrote:
> > 3) We don't have to always push sets of changes from an original pull
> > request to upstream; they can be consolidated using any of a
> variety of
> > methods to form a new local feature branch with the same net
> effect but
> > fewer commits (maybe only one), and then that can be merged (which
> > should be fast-forward, no merge commit) and pushed to upstream.
> This
> > takes a little more work than simply accepting (merging) a pull
> request
> > as-is, but in many cases it may be worth it because it can yield a
> > cleaner history. Similarly, if someone is developing a feature
> branch
> > on github, and the net effect is correct but the branch has
> intermediate
> > commits that distract from the net result, then a good practice
> would be
> > for that person to consolidate the changes into a new feature branch
> > with a cleaner history, close the pull request on the old one and
> open a
> > new request for the polished branch.
> >
> I believe this script more or less automates the process:
> https://github.com/jeresig/pulley
>
> Gerald.
>
>
> Don't know if this was a mistake or not, but I see that commit e7f1e83
> (the one to fix a clipping issue when a patch's line width is 1 but
> there is no color) seems to have been merged back into itself...
> somehow... in commit 0c886b8. I have seen things like this before, and
> I never quite understood how they happen. Plus, do we want to get that
> patch merged down to master?
Yes, it needs to get merged to master; but no, I don't think anything 
was "merged back into itself"; instead, it is just a case where a 
fast-forward with no merge commit would have left a simpler history--one 
commit instead of two.
Merging from v1.0.x to master doesn't have to be done after every change 
to v1.0.x, but it shouldn't be left undone for very long. A few days 
ago I wasted a chunk of time thrashing around on master because of a bug 
that had been fixed on 1.0.x but was not yet merged into master--and I 
had not thought to check their relative states. The bug had actually 
been introduced to master via a recent change merged from 1.0.x.
We are experiencing some bumps on the git/github learning curve, but not 
nearly enough to make me pine for svn.
>
> I think we definitely need to see what sort of controls we can put in
> place to prevent mix-ups in the future. One thing I did like about SVN
> was that it was next to impossible to change the history. Meanwhile,
> with git, it becomes possible. Is there some way we can disallow forced
> pushes, maybe? Just a thought...
>
I suspect the anomalies have not resulted from forced pushes, but from 
local pulls and merges followed by innocuous pushes. So the key is 
understanding how to ensure one's local branches have the desired 
history before pushing to github. (And making sure one is pushing from 
the correct source to the correct destination. Trying first with 
--dry-run can help.)
Eric
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 2011年5月18日 13:47:04 -0500, Benjamin Root wrote:
[clip]
> Don't know if this was a mistake or not, but I see that commit e7f1e83
> (the one to fix a clipping issue when a patch's line width is 1 but
> there is no color) seems to have been merged back into itself...
> somehow... in commit 0c886b8. I have seen things like this before, and
> I never quite understood how they happen.
"git merge --no-ff" most likely, as it always creates a separate
merge commit, even if the branch in question has only a single commit.
[clip]
> I think we definitely need to see what sort of controls we can put in
> place to prevent mix-ups in the future. One thing I did like about SVN
> was that it was next to impossible to change the history. Meanwhile,
> with git, it becomes possible. 
> Is there some way we can disallow forced pushes, maybe? Just a thought...
Disabling forced pushes will not help against what occurred here,
at least as far I understand, because the "additional" commits in the
pull requests come from valid merges done after the pull request branched.
The only difference to SVN here is that Git actually tracks the merge
history...
... and, apparently, the Github UI (but not Git itself) gets confused
in some cases as to what's new in a branch.
-- 
Pauli Virtanen

On Tue, May 17, 2011 at 9:07 PM, Gerald Storer <gd...@mr...> wrote:
> On 18/05/2011 5:14 AM, Eric Firing wrote:
> > 3) We don't have to always push sets of changes from an original pull
> > request to upstream; they can be consolidated using any of a variety of
> > methods to form a new local feature branch with the same net effect but
> > fewer commits (maybe only one), and then that can be merged (which
> > should be fast-forward, no merge commit) and pushed to upstream. This
> > takes a little more work than simply accepting (merging) a pull request
> > as-is, but in many cases it may be worth it because it can yield a
> > cleaner history. Similarly, if someone is developing a feature branch
> > on github, and the net effect is correct but the branch has intermediate
> > commits that distract from the net result, then a good practice would be
> > for that person to consolidate the changes into a new feature branch
> > with a cleaner history, close the pull request on the old one and open a
> > new request for the polished branch.
> >
> I believe this script more or less automates the process:
> https://github.com/jeresig/pulley
>
> Gerald.
>
>
Don't know if this was a mistake or not, but I see that commit e7f1e83 (the
one to fix a clipping issue when a patch's line width is 1 but there is no
color) seems to have been merged back into itself... somehow... in commit
0c886b8. I have seen things like this before, and I never quite understood
how they happen. Plus, do we want to get that patch merged down to master?
I think we definitely need to see what sort of controls we can put in place
to prevent mix-ups in the future. One thing I did like about SVN was that
it was next to impossible to change the history. Meanwhile, with git, it
becomes possible. Is there some way we can disallow forced pushes, maybe?
Just a thought...
Ben Root

Dear all,
When making plots, you want an log transfer of axis, but there are data
whose value is zero, at this time matplotlib prompts "Cannot take log of
nonpositive value",
but in most cases maybe you just want to check if the log axis make the plot
more nice-looking. So is it possible just change the function to make it
accept zero value
when making log transfer and set the the zero value on the log-transfered
plot remain as zero? By this way we don't have to change the zero value in
the data to a very small
value just for realizing the axis log transfer?
My matplotlib version is 0.91.2, Maybe in the new versions this has already
been done?
much thanks,
Chao
-- 
***********************************************************************************
Chao YUE
Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
UMR 1572 CEA-CNRS-UVSQ
Batiment 712 - Pe 119
91191 GIF Sur YVETTE Cedex
Tel: (33) 01 69 08 77 30
Portable Phone (Mobil phone) : (33) 07 60 54 23 71
************************************************************************************

On 18/05/2011 5:14 AM, Eric Firing wrote:
> 3) We don't have to always push sets of changes from an original pull
> request to upstream; they can be consolidated using any of a variety of
> methods to form a new local feature branch with the same net effect but
> fewer commits (maybe only one), and then that can be merged (which
> should be fast-forward, no merge commit) and pushed to upstream. This
> takes a little more work than simply accepting (merging) a pull request
> as-is, but in many cases it may be worth it because it can yield a
> cleaner history. Similarly, if someone is developing a feature branch
> on github, and the net effect is correct but the branch has intermediate
> commits that distract from the net result, then a good practice would be
> for that person to consolidate the changes into a new feature branch
> with a cleaner history, close the pull request on the old one and open a
> new request for the polished branch.
>
I believe this script more or less automates the process: 
https://github.com/jeresig/pulley
Gerald.