Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Once you throw away information, you can't get it back. Put the beautiful commit message into the merge commit if you must have it; I never find myself bothering. The "clutter" you mention is really a non-issue; git has powerful tools to browse/search history.

    • If you are like me, your topic branches are always rebased onto master frequently, and so when you merge into master you get a "fast-forward" commit: master (the pointer to the trunk of your tree) just suddenly points to the same commit as the branch you merged, and no new commit object is created.

      This can be a little bit annoying, because there is no way to tell that the last $N commits were all merged from a branch and belong together as a set, and that the real previous state of your trunk (for certain points of view) is $N commits back.

      To solve this, you can use the --no-ff option to git-merge, which prevents a fast-forward merge from occurring, thus creating a genuine commit object whose parent commits are the previous state of master and the state of the branch you are merging, which will happen to be the new state of master as well. This may facilitate better history browsing, although I'm not experienced enough to say for sure, yet. You might also like the --log option, which will add portions of all your commit messages to the merge commit message.

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers