Hg post-merge commit message, best practice?

I find myself doing the following a lot:

C:\Code>hg pull
pulling from http://server/FogBugz/kiln/Repo/Project/Rebuild/trunk
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 4 changes to 4 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

C:\Code>hg merge
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, dont forget to commit)

C:\Code>hg commit -m "Merged"

C:\Code>hg push
pushing to http://server/FogBugz/kiln/Repo/Project/Rebuild/trunk
searching for changes
开发者_如何学Cremote: kiln: successfully pushed 2 changesets

My question is, what is a better/more useful commit message to use after merging a pull from the repository. Are there any best practices that people use in distributed version control systems for this sort of thing?

If you use the fetch extension it automates the pull,merge step into one step, fetch. The message it auto-generates is something along the lines of "automatic merge". The hg developers seem to think this is reasonable as the extension is now distributed with the base.

Merge messages don't seem to be contain a particularly high amount of information. Your message seems reasonable.

[[ offtopic, we sometimes use them as an opportunity for a pun on the word merge]]

There is no one way so here is what I have tried to adhere to.

On commit messages:

Jus remember that those messages are the only strings that would connect you to some one who is try to decipher the reasons for the commit.

Key is to provide a description that is going to be a useful commentary on code development. So when some one uses hg log , he has a nice commentary on how the software is being developed.

Some good practices:

Link it with your bug management system:

1. fixes #3456, new feature #2435 etc
2. or a more descriptive one of what changes it is bringing in the repo
3. Give credits

In fact, what I do mostly is. Look at the current state of "hg log" and see what useful message would mean a logical progression in understanding the latest commit.

As long as "merg" is in the message somehow, we've had fun using the opportunity to fill our mercurial logs with hilarity. For example, we've used merge messages such as "real-estate mergage loans are at an all time low" or "a Merge Griffin television production."

You can collect all the newly added changesets' commit messages into a file by

$ hg log --rev 'reverse(p2():ancestor(p1(),p2())-ancestor(p1(),p2()))' \
         --template '{desc}\n' \
         > commit-message.txt

then manually edit commit-message.txt, and finally use it as the log message:

$ hg commit -l commit-message.txt

You could use the rebase extension, so hg pull --rebase would rebase your repo to the central repo's tip. This negates the need for merging after a pull.

I added an alias for it:

[alias]
pure = pull -u --rebase

Works well for us.

More details are at the RebaseProject page.

For mundane merges, where you're only working with one repository, I think just "merge" is fine. Usually you don't even know everything that got merged in because it's all other people's changes anyway.

The one time I would suggest being more verbose would be when you're working with more than one repository. If you have a devel repo and a stable repo, and you're pulling bug fixes in from stable, I would just mention that in the merge: "merging with stable". Those merges tend to be bigger, so it helps explain them to people who come along later.