Re: How to change merge message ("weenie commits")

From: Junio C Hamano <junkio@cox.net>
Date: Jan 25, 2007, 22:54 UTC
Message-ID: <7v1wli90q0.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <17848.54065.631799.755255@lisa.zopyra.com>

Bill Lear <rael@zopyra.com> writes:

Show 17 quoted lines

> I have developed a habit of using my SCM to provide local backup of my
> daily (hourly) work.  I often will work to a stopping point and commit
> my work, without any real coherence to the commit --- a sort of
> checkpoint.  These I call "weenie commits" because they are weenie-ish,
> unimportant in the larger scheme of things.
>
> When developing with others, I would like to be able to work in this
> way, tidily keeping my stuff tucked away in my SCM system, and then
> when I am ready to share, to convey to my peers what they need to
> know about my work, and not the 10,000 weenie commit messages that
> may be associated with my work.
>
> So, when I merge my topic branch onto master, for example, I'd like
> the commit message to be something more thoughtful than the
> "checkpoint 1", "checkpoint 2", "fix typo", "redo sort algorithm",
> etc., etc., and be more like a short set of release notes, a summary
> of what all has been accomplished.

Your message is titled as if it is about changing "merge message", but to clean-up history you would want to fix the commit boundary as well if your commits are "without any real coherence".

Which means that you need to first rebuild the topic branch to make it presentable before merging.

If all the work done in the weenie commits chain is really a single logical change in the bigger picture, then the answer is very simple: "git merge --squash". It's not a merge, but is to prepare your working tree to create a single commit for public consumption, and after committing you can (and probably should, in order to avoid confusing yourself) discard the branch with weenie commits.

Otherwise, what I often do myself is to export them as format-patch output, sift and reorder bits to make them coherent chunks and rebuild the series. It would go something like this:

	$ git checkout topic
	$ git format-patch master
	0001-snapshot-1.patch
	0002-snapshot-2.patch
	0003-snapshot-3.patch
	$ edit 00??-*.patch
	..	I come up with a fixed series which most likely
        ..	have different number of patch files.
        $ git checkout -b rebuilt topic~3 ;# go back to where I forked
        $ git am 0*-.patch.fixed
	$ git diff topic
        ..	This should match where I started, except I
	..	might have made small fix-ups while coming up
	..	with the *-patch.fixed series which should show up.
	$ test test test

        $ git branch -f topic
	$ git branch -d rebuilt
	..	Now the topic is cleaned-up so it is ready to be merged.
	..	we do not need the 'rebuilt' branch anymore.

        $ git checkout master
        $ git merge topic

I would also do "git rebase master" while on the "rebuilt" branch, because it is not a significant fact that I started my work on 'topic' at a particular commit in the past.