How to change merge message ("weenie commits")

How to change merge message ("weenie commits")

[Bill Lear]

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

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

[Santi Béjar]

On 1/25/07, Bill Lear <rael@zopyra.com> wrote:
> 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.

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

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

[J. Bruce Fields]

On Thu, Jan 25, 2007 at 09:56:33AM -0600, Bill Lear wrote:
> 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?

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.

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

[Seth Falcon]

Bill Lear <rael@zopyra.com> writes:
> 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?

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

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

[Karl Hasselström]

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

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

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, kha@treskal.com
      www.treskal.com/kalle

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

[Jakub Narebski]

Karl Hasselström wrote:

> On 2007-01-25 09:56:33 -0600, Bill Lear wrote:
> 
>> Do others run into this and perhaps have a good solution?
> 
> 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.

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.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Junio C Hamano]

Bill Lear <rael@zopyra.com> writes:

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

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

[Robin Rosenberg]

torsdag 25 januari 2007 16:56 skrev Bill Lear:
> 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?

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