Development:Helpful Mercurial Commands - Revision history

Sardisson: /* cross-commit substitutes */ add graft, for 2.0 and up

2012-01-16T06:10:31Z

cross-commit substitutes: add graft, for 2.0 and up

Sardisson: /* Mercurial Queues */

2011-11-03T05:21:58Z

Mercurial Queues

Sardisson: /* transplant */ add transplant.sh

2011-09-08T04:22:45Z

transplant: add transplant.sh

Sardisson: add links to two general tutorials for helping users get their Hg legs

2010-08-30T01:49:47Z

add links to two general tutorials for helping users get their Hg legs

Sardisson: /* cross-commit substitutes */ add a section on using hg import for patches with moves/copies

2010-08-16T20:15:49Z

cross-commit substitutes: add a section on using hg import for patches with moves/copies

Sardisson: /* rename (mv) */ more scary warning up front

2010-08-16T20:05:51Z

rename (mv): more scary warning up front

Sardisson: /* rebase */ taking bz only-slightly-out-of-context from #developers

2010-06-09T04:06:36Z

rebase: taking bz only-slightly-out-of-context from #developers

Sardisson: /* outgoing */ add a stub for rebase in order to include warnings about blame-corruption

2010-06-08T19:12:18Z

outgoing: add a stub for rebase in order to include warnings about blame-corruption

Sardisson: /* rename (mv) */ big warning against hg addremove, which is evil, and dumb, to boot!

2010-06-08T18:38:41Z

rename (mv): big warning against hg addremove, which is evil, and dumb, to boot!

Sardisson: /* import */ oops, fix this, too

2010-06-05T02:38:55Z

import: oops, fix this, too

← Older revision		Revision as of 06:10, 16 January 2012
Line 49:		Line 49:

	Fortunately, Mercurial has a couple of tools to ease cross-landings, and, while they have their shortcomings like <code>cross-commit</code>, they will fail '''before you push''' to the remote repository, making it possible, with a little effort, for you to notice failures before pushing and preventing you from landing only part of a patch on the second branch.		Fortunately, Mercurial has a couple of tools to ease cross-landings, and, while they have their shortcomings like <code>cross-commit</code>, they will fail '''before you push''' to the remote repository, making it possible, with a little effort, for you to notice failures before pushing and preventing you from landing only part of a patch on the second branch.
		+
		+	===graft===
		+
		+	In Mercurial 2.0 and newer, the built-in [http://www.selenic.com/mercurial/hg.1.html#graft graft] command is a similar but slightly more flexible version of [[#transplant\|transplant]] extension. It offers options to adjust the username and commit dates, as well as directly edit the commit message (instead of requiring a round-about filter invocation). It will not, however, work across repositories; it only works with branches.
		+
		+	'''Not yet tested in Camino development'''

	===transplant===		===transplant===

← Older revision		Revision as of 05:21, 3 November 2011
Line 112:		Line 112:
	[4:00pm] ardissone: which were generally useful to helping me get acquainted to the differences		[4:00pm] ardissone: which were generally useful to helping me get acquainted to the differences
	between hg and cvs, but not so much for the mozilla-specific stuff (or mq)</pre>		between hg and cvs, but not so much for the mozilla-specific stuff (or mq)</pre>
		+
		+	==Appendix==
		+	* [http://jlebar.com/2011/5/20/Faster_and_smaller_clones_of_branches.html Faster and smaller clones of branches]

@@ Line 56: / Line 56: @@
 You’ll want to use this method of “cross-landing” for a traditional cross-landing, i.e., landing a patch on two branches at exactly the same time during normal development.
-<code>hg transplant</code> is '''not recommended''' for backporting patches to a stable “branch” because the commit will reflect the patches’ original landing dates and comments, not the current date and any approvals.  (The <code>--filter</code> argument is supposed to allow modifying the commit message, but not interactively—only a single, pre-specified addition—and also will not change the commit date.)
+<code>hg transplant</code> is '''not recommended''' for backporting patches to a stable “branch” because the commit will reflect the patches’ original landing dates and comments, not the current date and any approvals.  (The <code>--filter</code> argument is supposed to allow modifying the commit message, but not interactively—only a single, pre-specified addition—and also will not change the commit date.  However, this [http://hg.mozilla.org/users/alqahira_ardisson.org/misc/file/tip/transplant.sh filter script] will allow you to either append a specified standard approval message or interactively edit the commit message of each changeset.)
 ===import===

← Older revision		Revision as of 01:49, 30 August 2010
Line 2:		Line 2:

	For more information about any of these commands, use <code>hg --help $cmdname</code>.		For more information about any of these commands, use <code>hg --help $cmdname</code>.
		+
		+	''This document assumes you have general familiarity with version control systems and with the basics of cloning, pulling, and diffing with Mercurial. For an introduction, see [http://hginit.com/ Hg Init] by Joel Spolosky (of “Joel on Software” fame) and/or [http://hgbook.red-bean.com/ Mercurial: The Definitive Guide] by Bryan O'Sullivan.''

	==rename (mv)==		==rename (mv)==

← Older revision		Revision as of 20:15, 16 August 2010
Line 33:		Line 33:

	<pre>[12:05am] bz: I fundamentally don't trust rebase</pre>		<pre>[12:05am] bz: I fundamentally don't trust rebase</pre>
		+
		+	==Applying a patch with renames, copies, or binary files==
		+
		+	Sometimes you may wish to apply a patch that contains changes generated by the <code>rename</code> (<code>mv</code>) or <code>copy</code> commands (or if a patch contains binary files, which is strongly discouraged in Camino development, but which you may encounter if you are backporting a changeset from hgweb, for instance). The venerable <code>patch</code> command cannot handle moves or copies and may end up patching the wrong files.
		+
		+	To handle these types of patches (e.g., [https://bugzilla.mozilla.org/attachment.cgi?id=465542 attachment 465542] on {{bug\|521137}}), you must instead use Mercurial’s <code>import</code> command to apply the patch. By default <code>import</code> commits the changes, which you may not want to do (particularly if you are only applying the patch for review or testing purposes), so you should add the <code>--no-commit</code> option. In addition, even with the <code>--no-commit</code> option, <code>import</code> will refuse to apply the patch if you have local changes elsewhere in your tree, so you may have to add the <code>--force</code> option as well.
		+
		+	Thus, assuming you have no conflicting local changes in files touched by the patch, <code>hg import --no-commit --force /path/to/patch</code> (note the lack of <code><</code> redirect compared to <code>patch</code>) should successfully apply a patch that contains Mercurial file moves or copies (or changeset from hgweb that includes binary files) for testing purposes, without making a commit.

	==cross-commit substitutes==		==cross-commit substitutes==

@@ Line 6: / Line 6: @@
 To move or rename a file managed by Hg, simply <code>hg mv $source $destination</code>, and Hg will move the contents of the file to the new name/location, mark the old name/location for deletion, and mark the new name/location for addition.
-Many Mercurial tutorials instead recommend moving the file “outside” of hg and then using <code>hg addremove</code> to clean up; '''you should not use <code>hg addremove</code>, because it will [http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/fe821769f03d09d6# corrupt blame] for the file(s)'''.
+Many Mercurial tutorials instead incorrectly recommend moving the file “outside” of hg and then using <code>hg addremove</code> to clean up; '''you should not use <code>hg addremove</code>, because it will [http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/fe821769f03d09d6# corrupt blame] for the file(s)'''.
 ==rollback==

← Older revision		Revision as of 04:06, 9 June 2010
Line 31:		Line 31:

	'''You should be extremely careful using <code>hg rebase</code> with changes that include file moves or renames''', as <code>hg rebase</code> has a history of transforming moves/renames into separate additions and removals, which '''[http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/fe821769f03d09d6 corrupts blame]'''.		'''You should be extremely careful using <code>hg rebase</code> with changes that include file moves or renames''', as <code>hg rebase</code> has a history of transforming moves/renames into separate additions and removals, which '''[http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/fe821769f03d09d6 corrupts blame]'''.
		+
		+	<pre>[12:05am] bz: I fundamentally don't trust rebase</pre>

	==cross-commit substitutes==		==cross-commit substitutes==

← Older revision		Revision as of 19:12, 8 June 2010
Line 25:		Line 25:

	<code>hg outgoing</code> will tell you what changesets (commits) you are about to push to the official repository with <code>hg push</code>.		<code>hg outgoing</code> will tell you what changesets (commits) you are about to push to the official repository with <code>hg push</code>.
		+
		+	==rebase==
		+
		+	Mercurial has a <code>hg rebase</code> command, similar to git’s command of the same name. This command helps you to avoid merging by recreating your changes on top of a newer source revision. ''Someone who understands rebase should write the rest of this paragraph.''
		+
		+	'''You should be extremely careful using <code>hg rebase</code> with changes that include file moves or renames''', as <code>hg rebase</code> has a history of transforming moves/renames into separate additions and removals, which '''[http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/fe821769f03d09d6 corrupts blame]'''.

	==cross-commit substitutes==		==cross-commit substitutes==

@@ Line 40: / Line 40: @@
 ===import===
-Option 2 is to use the <code>hg import</code> command.  <code>hg import -u $user -m $path-to-patch</code> (where path-to-patch is a patch file, a patch on a bug, or a changeset’s <code>raw-rev</code> URL in a remote repository) will import the patch and let you specify the patch author and checkin comment (e.g., an approval).  If you have a <code>raw-rev</code> URL or a patch generated by <code>hg export</code>, you can omit the <code>-u $user</code> argument.  To prevent committing (e.g., if a change on a “branch” needs changes in an additional file), add the <code>--no-commit</code> argument.
+Option 2 is to use the <code>hg import</code> command.  <code>hg import -u $user -m $path-to-patch</code> (where ''$path-to-patch'' is a patch file, a patch on a bug, or a changeset’s <code>raw-rev</code> URL in a remote repository) will import the patch and let you specify the patch author and checkin comment (e.g., an approval).  If you have a <code>raw-rev</code> URL or a patch generated by <code>hg export</code>, you can omit the <code>-u $user</code> argument.  To prevent committing (e.g., if a change on a “branch” needs changes in an additional file), add the <code>--no-commit</code> argument.
 Drawbacks of this method include the fact it requires you to have git-style diffs enabled in your <code>~/.hgrc</code>, it requires you to retype the commit message to add the approval, and that the [http://weblogs.mozillazine.org/gerv/archives/2010/06/hg_transplant.html#comments handling of binary files and moves/renames have been flaky] in various versions of Mercurial.