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

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

Thread Previous | Thread Next
From:
Karl Williamson
Date:
August 2, 2012 09:01
Subject:
Re: [perl.git] branch blead, updated. v5.17.2-69-g4a74e76
Message ID:
501AA44F.9020000@khwilliamson.com
On 07/26/2012 11:49 PM, Jesse Luehrs wrote:
> 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.
>
> -doy
>


This doesn't work.  What it did was to bring everything in-line and 
throw away the merge commit.

And it isn't clear to me when we need a merge commit anyway.  perlgit 
says this: "For larger sets of commits that only make sense together, or 
that would benefit from a summary of the set's purpose, you should use a 
merge commit."  Is that accurate?

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