I was wondering if there was a git rebase --interactive "squash"
alternative, that instead of letting me edit and manually combine the
commit messages from multiple commits that I want squashed together,
instead simply used the first and folded the other commits into that?
I often find myself in the following pattern:
branch, hack, commit.
hack, commit, hack, commit
git rebase --interactive master
squash later commits into an earlier one
repeated [hack, commit]+, rebase, squash
merge
At which point, 99% of the time I want to fold the later commits into
an earlier commit, keep the commit message of the first and throw the
remaining commit messages into /dev/null.
I understand this is just a matter of editting the commit messages,
but I'm lazy and I find myself repeatadly dumbly deleting the latter
commit messages again and again.
A $EDITOR macro/extension might address this, but it seems (to me)
cleaner to extend the rebase command set:
< pick, edit, squash
pick, edit, squash, fold
"fold" is perhaps the wrong word. "squish" is perhaps too similar.
"rollup" maybe?
In any event, functionally it would do exactly the same as "squash",
except rather than let you edit the commit messages it would instead
simply use the commit message of the first commit. And throw the
other commit messages away.
I'm not adverse at having a go at putting a patch together (although
this is not my forte), but I thought I'd check there wasn't prior art
or a good reason why this would be a "bad thing" to have?
Murray.
branch, hack, commit.
hack, commit, hack, commit
What if you used commit --append instead?
The trouble though of squashing all the commits into one is that it
makes it impossible to bisect later. Are you really sure that your
final commit cannot be broken into small commits? Ideally each commit
is small but self contained. Squashing should be done only to fix
cases where you introduced a bug then fixed it, or to fix a partial
implementation etc.
John
On Wed, Jun 17, 2009 at 1:55 PM, John Tapsell [off-list ref] wrote:
quoted
branch, hack, commit.
hack, commit, hack, commit
What if you used commit --append instead?
That appears to be a switch I don't have, nor is documented
http://www.kernel.org/pub/software/scm/git/docs/git-commit.html
Did you perhaps mean --amend? Or have I missed something?
--amend is not really a solution for me - it is perhaps a quirk of my
working pattern, but I typically (on the branch) commit tiny tiny bits
of a (possibly incomplete) feature, then want to merge them back into
a single "feature commit" to merge with trunk. It's a case of
building up a feature commit one step at a time.
Perhaps I'm not normal or going about it wrong, in that I'm happy to
commit (on a branch) an incomplete bit of code ... pop off to do
something else, come back, hack a little more ... go off, come back
... eventually ending up with a bunch of commits I want to merge down
into a smaller set of (combined) commits which to then merge with
master/trunk.
fwiw, I didn't set out with this pattern in mind, it's rather one I
have noticed myself being in frequently. It seems quite natural to
me, except for this repeated squashing mini commits down. I'm not
squashing ALL commits down into one single commit. Rather many
commits down into a few commits, which then get merged with
master/trunk.