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
-

[ message continues ]

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
-

[ message continues ]

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.
-

[ message continues ]

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
-

[ message continues ]

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
[ message continues ]

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.


-

[ message continues ]

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
-

[ message continues ]