How to change merge message ("weenie commits")

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.

Do others run into this and perhaps have a good solution?

Bill

On 1/25/07, Bill Lear <rael@zopyra.com> wrote:

I think the --no-commit flag to git-merge/git-pull (man git-pull) is what you are looking for, or a git commit --amend.

Santi

On Thu, Jan 25, 2007 at 09:56:33AM -0600, Bill Lear wrote:

I tend to do something vaguely like:

	git checkout -b dirtywork origin

Then make a bunch of commits as you describe above--poorly commented, not necessarily logically split up, etc.--then when it's ready,

	git checkout -b cleanwork origin
	git diff cleanwork..dirtywork

Examine the diff, figure out which change should go logically first, apply that one change and commit, and then again run

	git diff cleanwork..dirtywork

Repeat until the diff is empty (except maybe for a few improvements I noticed as I went along). Then finally

	git push publicrepo cleanwork:master
	git branch -D dirtywork

Or something like that.

--b.

Bill Lear <rael@zopyra.com> writes:

Suppose you do your daily work on branch weenie, then one way would be:

  git format-patch -k master..weenie
  git checkout master
  git apply 00*.patch
  ## review, then git add and git commit where you would write a long
  ## commit message.

One nice thing about this workflow is that you can easily decide if you want one single commit or a few commits to group logical groups of the patch files.

+ seth

On 2007-01-25 09:56:33 -0600, Bill Lear wrote:

I make lots of small commits, then periodically rewrite history with StGIT to get the nice-looking set of commits I wish I had made in the first place. I don't think I do anything that couldn't be done with just git, but StGIT is made precisely for this kind of work, and is quite good at it.

Karl Hasselström wrote:

If you want to use only core git, "git cherry-pick" (with or without --no-commit option), "git commit --amend" and "git merge --squash" (and probably "git rebase --onto") are your friends. You can also do "git format-patch", edit/reorder patches and then "git am --3way" or "git apply".

But StGIT is made for this work. I use it to reorder commits, to amend commit deeper in the history, to split and join commits (although it is more work, at least with version I use). If you have branch which is currently not managed by StGIT, "stg init" and then use "stg uncommit". I frequently use "stg uncommit" and "stg pop"/"stg push" to add commit in the middle of branch.

Bill Lear <rael@zopyra.com> writes:

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.

torsdag 25 januari 2007 16:56 skrev Bill Lear:

I agree with Karl. Stacked Git is the tool. It doesn't help in splitting muliple changes to one file so you have to do that manually with e.g. emacs.

-- robin