Front page | perl.perl5.porters |
Postings from July 2012
On Thu, Jul 26, 2012 at 11:46:23PM -0600, Karl Williamson wrote: > On 07/26/2012 09:15 PM, Ricardo Signes wrote: > >Secondly, the merging here made just a bit of a mess. This is the history > >graph where the merges happened: > > > > * [513f78f] op.c:op_free: Rmv dead code; simplify cop_free logic > > * [4a74e76] Merge branch 'blead' of ssh://perl5.git.perl.org/perl into blead > > |\ > > | * [6bd66ee] In Perl_magic_setenv() s/ptr/key/ in two pieces of ... > > * | [53335a3] Merge branch 'khw/invlist' into blead > > |\ \ > > | |/ > > |/| > > | * [a0a0694] regcomp.c: Revise bracketed char class optimizations > > > >My assumption here is that 53335a3 was made locally, then could not be pushed > >because 6bd66ee had become the new public blead. 4a74e76 was then made and > >pushed. Instead, 53335a3 should have been discarded and a new merge commit > >with both a0a0694 and 6bd66ee as its parents should have been made. > > > >That is, the history should've looked like: > > > > * [???????] op.c:op_free: Rmv dead code; simplify cop_free logic > > * [???????] Merge branch 'khw/invlist' into blead > > |\ > > | * [a0a0694] regcomp.c: Revise bracketed char class optimizations > > * | [6bd66ee] In Perl_magic_setenv() s/ptr/key/ in two pieces of ... > > > >In this case, the complication is minor and the likely burden on future > >bisectors is similarly minor, but we should all remain mindful of these kind > >of messy merges, since they're so very easy to avoid. > > > I forgot to update blead before the merge commit, or else the other > commit was made while I was making the merge one--I'm not sure, > haven't checked, but it was probably the former. > > I did a 'git push' and got a rejection message. I followed what git > told me to do in that message, and that is to do a 'git pull' and > try again. I pondered whether that should be a 'git pull --rebase', > but decided to follow its instructions exactly. I was surprised > later to see an extra merge that git added that I hadn't specified. > > The instructions in perlgit should be updated (by somebody who knows > what they are doing) to that one shouldn't follow git's instructions > when this happens, but to follow other procedures instead. git pull --rebase is the right thing to do here. -doyThread Previous | Thread Next