15

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
remote: 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?

automagic
  • 1,067
  • 8
  • 10
  • Sounds like what I do .... Guess that makes two of us (and all the guys I work with too!) maybe not doing best practices ... – jcolebrand Oct 20 '10 at 20:51
  • IMHO these merge messages (and commits) are a flaw of hg. In subversion you have the log messages of the previous commits, then svn up is doing an automatic merge then you can commit only *your* changes with of course the right log message. I would like in a future version of hg to have not only empty merge commit messages, but also no event at all in the timeline for that! Should we always use "hg pull --rebase" as suggested? Did I miss something? please point me to an explanation.. ;-). Cheers – Christophe Muller Oct 21 '10 at 08:46

6 Answers6

9

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

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Paul Rubel
  • 26,632
  • 7
  • 60
  • 80
  • Perfect, in fact, I already had this installed and didn't even know it! Thanks! – automagic Oct 20 '10 at 21:11
  • 1
    The fetch extension clutters up your history with meaningless merge messages. Just something to consider. – Robert S. Oct 20 '10 at 22:12
  • 2
    Just to insert a reason behind my downvote: I think pyfunc's suggestion that they give a "why" is really a better idea. Mine tend to be things like "bringing in bugfix # from production branch" or "pulling in Jim's new feature Y". The fetch extension ships with mercurial, but it's disabled by default and for good reason. – Ry4an Brase Oct 20 '10 at 22:14
  • 2
    @Ry4an I can see what you're saying but most of the merges are just other people's developments. What's in those commits is already in the logs, with the given patches. A merge is potentially a big ball of mud if you're merging with something that's merged with two other folks. If you can concisely say what's merged, it seems reasonable to do so, but at least in my development I don't see that being the case very often. – Paul Rubel Oct 21 '10 at 00:22
  • 1
    @Robert S. what's the alternative? An empty message? Is there a repo out there with good merge messages you could point us to? – Paul Rubel Oct 21 '10 at 00:24
  • 1
    We use the rebase extension, noted in http://stackoverflow.com/questions/3982111/hg-post-merge-commit-message-best-practice/3982421#3982421. – Robert S. Oct 21 '10 at 14:46
6

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.

pyfunc
  • 65,343
  • 15
  • 148
  • 136
  • Thanks for your answer. We follow a very similar practice and it works very well. I try to base my own messages on cases where I have needed to look through the history. Generally messages which state the main purpose of the commit are what I find most useful. Additional details beyond that may actually get in the way. – StayOnTarget Jul 06 '16 at 00:05
2

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

mstringer
  • 2,242
  • 3
  • 25
  • 36
1

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
jpsecher
  • 4,461
  • 2
  • 33
  • 42
1

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.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Robert S.
  • 25,266
  • 14
  • 84
  • 116
  • 1
    Note that this has the same effect as `svn update`, meaning that you're still merging code, it's just done in the background and without a safety net. If the merge fails because of conflicts, you can't just revert and try again, you have to dig changes out of .rej files. It also combines your changes with the merge, so some of the changes that you check in will also be other people's changes getting merged in. TL;DR Don't be afraid to merge, it's safer. – tghw Oct 20 '10 at 21:37
  • It doesn't use .rej files. It saves the bundle in the .hg folder, which you can unbundle if your operation goes south. I've updated my post with a link to the RebaseProject, which provides more details. The analog to `svn update` is `hg pull -u`. Have a look at http://stackoverflow.com/questions/2354527/is-hg-pull-rebase-analogous-to-svn-update. Don't be afraid to try something different. – Robert S. Oct 20 '10 at 22:11
0

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.

tghw
  • 25,208
  • 13
  • 70
  • 96
  • Thanks for your response. Along the same lines, the nice thing about the fetch extension mentioned above is that it does exactly that- tells you exactly what repo you pulled and merged. – automagic Oct 20 '10 at 22:04