use Perl

• do not squash (Score:1)

  by hdp (1658)

  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.
  • Re: (Score:2)

    by jdavidb (1361)

    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 p

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
• Re: seeking git wisdom: to squash or not to squash (Score:1)

  by daxim (8218)

  squash only commits that should have been a single commit in the first place.

  pick deadbee add frobnitzers to lib/*.pm
  pick fab4cab switch tests to new scheme
  pick b00b135 oops, forgot files in lib/ subdirs

  ↓

  pick deadbee add frobnitzers to lib/*.pm
  s b00b135 oops, forgot files in lib/ subdirs
  pick fab4cab switch tests to new scheme
• Focussed commits are better (Score:1)

  by Aristotle (5147)

  What daxim said.

  Also, another option is, if no one else has worked on the branch but you, you could rebase it onto master to linearise the history, making it easier to read.

  But don’t squash entire branches in order to merge them. Focussed commits are easier to understand. They are also far more useful to git bisect.

  If you feel the need for good merge commit messages, just write them yourself, as hdp said.