• Choose a category
• All
• Classic-Fiction

changeset: 73:584af0e231be

user: Censored Person

date: Tue Sep 26 21:37:07 2006 -0700

summary: include buildmeister/commondefs. Add exports.

As far as the remainder of the contents of the commit message are concerned, there are no hard-and-fast rules. Mercurial itself doesn’t interpret or care about the contents of the commit message, though your project may have policies that dictate a certain kind of formatting.

My personal preference is for short but informative commit messages that tell me something that I can’t figure out with a quick glance at the output of hg log --patch.

If we run the hg commit command without any arguments, it records all of the changes we’ve made, as reported by hg status and hg diff.

* * *

A surprise for Subversion users

Like other Mercurial commands, if we don’t supply explicit names to commit to the hg commit, it will operate across a repository’s entire working directory. Be wary of this if you’re coming from the Subversion or CVS world, since you might expect it to operate only on the current directory that you happen to be visiting and its subdirectories.

* * *

Aborting a Commit

If you decide that you don’t want to commit while in the middle of editing a commit message, simply exit from your editor without saving the file that it’s editing. This will cause nothing to happen to either the repository or the working directory.

Admiring Our New Handiwork

Once we’ve finished the commit, we can use the hg tip command to display the changeset we just created. This command produces output that is identical to hg log, but it only displays the newest revision in the repository:

$ hg tip -vp

changeset: 5:12efb75cbece

tag: tip

user: Bryan O'Sullivan

date: Tue May 05 06:44:49 2009 +0000

files: hello.c

description:

Added an extra line of output

diff -r 2278160e78d4 -r 12efb75cbece hello.c

--- a/hello.c Sat Aug 16 22:16:53 2008 +0200

+++ b/hello.c Tue May 05 06:44:49 2009 +0000

@@ -8,5 +8,6 @@

int main(int argc, char **argv)

{

printf("hello, world!\");

+ printf("hello again!\n");

return 0;

}

We refer to the newest revision in the repository as the tip revision, or simply the tip.

By the way, the hg tip command accepts many of the same options as hg log, so -v above indicates “be verbose” and -p specifies “print a patch.” The use of -p to print patches is another example of the consistent naming we covered earlier.

Sharing Changes

I mentioned earlier that repositories in Mercurial are self-contained. This means that the changeset we just created exists only in our my-hello repository. Let’s look at a few ways that we can propagate this change into other repositories.

Pulling Changes from Another Repository

To get started, let’s clone our original hello repository, which does not contain the change we just committed. We’ll call our temporary repository hello-pull:

$ cd ..

$ hg clone hello hello-pull

updating working directory

2 files updated, 0 files merged, 0 files removed, 0 files unresolved

We’ll use the hg pull command to bring changes from my-hello into hello-pull. However, blindly pulling unknown changes into a repository is a somewhat scary prospect. Mercurial provides the hg incoming command to tell us what changes the hg pull command would pull into the repository, without actually pulling the changes in:

$ cd hello-pull

$ hg incoming ../my-hello

comparing with ../my-hello

searching for changes

changeset: 5:12efb75cbece

tag: tip

user: Bryan O'Sullivan

date: Tue May 05 06:44:49 2009 +0000

summary: Added an extra line of output

Bringing changes into a repository is a simple matter of running the hg pull command, and optionally telling it which repository to pull from:

$ hg tip

changeset: 4:2278160e78d4

tag: tip

user: Bryan O'Sullivan

date: Sat Aug 16 22:16:53 2008 +0200

summary: Trim comments.

$ hg pull ../my-hello

pulling from ../my-hello

searching for