Front page | perl.perl5.porters |
Postings from August 2012
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