Bill Lear <rael@xxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html