develooper Front page | perl.perl5.porters | Postings from July 2012

Re: [perl.git] branch blead, updated. v5.17.2-69-g4a74e76

Thread Previous | Thread Next
From:
Karl Williamson
Date:
July 26, 2012 22:46
Subject:
Re: [perl.git] branch blead, updated. v5.17.2-69-g4a74e76
Message ID:
50122B2F.10305@khwilliamson.com
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.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About