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:
Dave Mitchell
Date:
August 2, 2012 13:18
Subject:
Re: [perl.git] branch blead, updated. v5.17.2-69-g4a74e76
Message ID:
20120802201458.GD2763@iabyn.com
On Thu, Aug 02, 2012 at 10:01:19AM -0600, Karl Williamson wrote:
> 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?

Yes. But note that in this case, it should still be rebased.

[ In the following,  H is the most recent HEAD on origin/blead; h is
the old HEAD when you last pulled, + are your commits, * are other commits ]

If you just have a couple of commits, your repository will look like:

    +    <= HEAD
    |
    +
    |
    h    <= blead, origin/blead
    |
    *

After an optional 'git fetch', it will look like:

    H      <= origin/blead
    |
    *
    |
    *  +    <= HEAD
    |  |
    *  +
    |  |
    *  +
    |/
    h      <= blead
    |

you then do 'git pull --rebase', ready for the 'git push':

    +'    <= HEAD, blead
    |
    +'
    |
    +'
    |
    H     <= origin/blead
    |
    *
    |
    *
    |
    *
    |
    h
    |

If on the other hand you have a whole bunch of commits, like my
davem/re_eval branch, you push it as a merge commit, *but* only after
rebasing.  So initially:

    +    <= HEAD, davem/re_eval
    |
    +
   ... (lots of commits)
    +
    |
    h    <= blead, origin/blead
    |

after 'git checkout blead; git pull' :

    H      <= HEAD, blead, origin/blead
    |  +   <= davem/re_eval
    *  |
    |  +
    *  |
    |  +
    |/
    h
    |

after 'git checkout davem/re_eval; git rebase blead' :

      +'   <= HEAD, davem/re_eval
      |
      +'
      |
      +'
     /
    H      <= blead, origin/blead
    |
    *
    |
    *
    |
    h
    |

after 'git checkout blead; git merge --no-ff --no-commit davem/re_eval':

    X      <= blead
    |\
    | +'   <= HEAD, davem/re_eval
    | |
    | +'
    | |
    | +'
    |/
    H      <= origin/blead
    |
    *
    |
    *
    |
    h
    |

where X is an (uncommited) merge commit, that merges the two branches, but
where crucially, one branch is empty. That way you document in the commit
structure that a set of commits belong together, but without hiding a
bunch of details about how the two branches were merged.

Finally, do 'git commit' to add a suitable long comment to the 'X' commit
explaining the overall purpose of the branch just being merged in.

-- 
Art is anything that has a label (especially if the label is "untitled 1")

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