matplotlib-devel Mailing List for matplotlib

On 2011年5月17日 16:14:53 -0400, Michael Droettboom wrote:
> Darned if I know what I did differently that time. (I'm sure I hit
> git's "misunderstanding" feature again).
> 
> It only seems to have affected 2 or 3 of the pull requests -- I suspect
> rebasing those branches off of the current master would fix the problem,
> but maybe there's an easier way.
Looks like some Github quirk:
 git log master..scottza/fix-autofmt_xdate-twinx
shows only four commits.
The merges done after 2011年02月19日 seem to have connected a chunk of
previously unconnected 0_91_maint history to master.

On 05/17/2011 10:14 AM, Michael Droettboom wrote:
> Darned if I know what I did differently that time. (I'm sure I hit
> git's "misunderstanding" feature again).
>
> It only seems to have affected 2 or 3 of the pull requests -- I suspect
> rebasing those branches off of the current master would fix the problem,
> but maybe there's an easier way.
Mike,
First, regarding the pull requests, I think that in some cases it is not 
a problem because they are being closed (rejected or superseded), and in 
any case, it is easy to handle them locally and then ensure a clean 
changeset to be pushed up to the main repo. So they look terrible in 
the github web view, but no real damage is done to the information in 
the branches they represent when one pulls those branches and works with 
them locally.
Second, I think the problems came from one or two exceptions to 
recommended git practice (this is coming from a git non-expert, so take 
with a grain of salt; git experts, please chime in and correct me as 
needed), which appear to be of two types: one is pulling from "origin" 
when you intended to pull from "upstream":
* | | commit 14406a68c039dc6578730f23955bf34d34008a08
|\ \ \ Merge: fdf5fae 132f967
| | | | Author: Michael Droettboom <md...@gm...>
| | | | Date: Fri May 6 15:25:01 2011 -0400
| | | |
| | | | Merge remote branch 'origin/v1.0.x'
(this is the one that deleted scads of files, which you replaced in the 
subsequent commit)
and the other is merging from origin or upstream into a feature branch:
| | * | commit 668ef6d826eff5eb4aac6251e1ddd9ac713616e5
| | |\ \ Merge: de18d9a 53f8139
| | |/ / Author: Michael Droettboom <md...@gm...>
| |/| | Date: Thu May 12 11:43:48 2011 -0400
| | | |
| | | | Merge remote branch 'upstream/v1.0.x' into gtk_crash
My understanding is that:
1) merges should always be from a feature branch into v1.0.x or master 
(and from v1.0.x into master, not the reverse); this can be done by 
updating local copies of v1.0.x etc from upstream, merging from the 
feature branch, and then pushing to upstream.
2) If a feature branch is local only (no one else has it) then it can be 
rebased so that merging it into v1.0.x etc. does not involve a merge 
commit; but if the feature branch has been published on github, then it 
should not be rebased.
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.
Regarding your 14406a commit: if I understand correctly, a better 
recovery method would have been to use
git reset --hard HEAD^
to simply back up the branch pointer by one.
The bad commit would still be in your local tree, but it would be 
un-named (that is, it would have no branch name) and would not go 
anywhere else.
Eric
>
> Mike
>
> On 05/17/2011 03:16 PM, Eric Firing wrote:
>> I suspect that the series of May 6 commits ending with
>> a50874b711983cba505ecdb2801c4996eccf3812 has tangled the history in such
>> a way that some (but not all) older pull requests on github like this one
>>
>> https://github.com/matplotlib/matplotlib/pull/1
>>
>> are showing hundreds of commits and diffs.
>>
>> Eric

Darned if I know what I did differently that time. (I'm sure I hit 
git's "misunderstanding" feature again).
It only seems to have affected 2 or 3 of the pull requests -- I suspect 
rebasing those branches off of the current master would fix the problem, 
but maybe there's an easier way.
Mike
On 05/17/2011 03:16 PM, Eric Firing wrote:
> I suspect that the series of May 6 commits ending with
> a50874b711983cba505ecdb2801c4996eccf3812 has tangled the history in such
> a way that some (but not all) older pull requests on github like this one
>
> https://github.com/matplotlib/matplotlib/pull/1
>
> are showing hundreds of commits and diffs.
>
> Eric
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

I suspect that the series of May 6 commits ending with 
a50874b711983cba505ecdb2801c4996eccf3812 has tangled the history in such 
a way that some (but not all) older pull requests on github like this one
https://github.com/matplotlib/matplotlib/pull/1
are showing hundreds of commits and diffs.
Eric