All the Perl that's Practical to Extract and Report
use Perl Log In
domm (4030)
(email not shown publicly)
http://domm.plix.at/
Just in case you like to know, I'm currently full-time father of 2 kids, half-time Perl hacker, sort-of DJ, bicyclist, no longer dreadlocked and 33 years old
I'm also head of Vienna.pm [pm.org], maintainer of the CPANTS [perl.org] project, member of the TPF Grants Commitee [perlfoundation.org] and the YAPC Europe Foundation [yapceurope.org].
I've got stuff on CPAN [cpan.org], held various talks [domm.plix.at] and organised YAPC::Europe 2007 in Vienna [yapceurope.org].
seeking git wisdom: to squash or not to squash
I guess this question has no correct answer, but I'd still appreciate any feedback.
I'm currently trying to find my personal preferred git style. There are a few things I'm sure about:
- master is the stable, i.e. what's running on live (and what could be released at any time)
- bug fixes and features should be done in topic branches, which might or might not be pushed to public (depending mainly on how long it takes to implement them)
- We're using gitosis
When I'm done with a topic branch and about to merge it back into master, I see two options: Just merge it. Or use git rebase --interactive to squash all commits I did into one, and than merge that.
The plain merge has the advantage that a lot of small commits are easier to merge (or so I've been told). Plus it's easier to revert/bisect later. The disadvantage is a lot of clutter in the history / git log.
If I squash all of my commits into one, I can avoid that clutter (and one can write beautiful commit messages after an rebase --interactive). But than this single big commit might be hard to merge. And a lot of fine grained information is lost.
So, can you offer any insights on this question? (hm, and maybe I should post this on some git list or on stackoverflow.com...)
Or is it a BUG?"
"Let's call it an accidental feature. :-)"
--Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
do not squash (Score:1)
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)
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)
↓
Focussed commits are better (Score:1)
What daxim said.
Also, another option is, if no one else has worked on the branch but you, you could rebase it onto
masterto 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.