Mercury Cherry Changes for Fixation

Let's say I made a lot of changes to my code and I only need to commit some of these changes. Is there a way to do this in mercury? I know darcs has a function like this.

I know that hg transplant can do this between branches, but I need something like this to execute the code in the current branch, and not when adding change sets from any other branch.

+53
mercurial change-management
May 12, '09 at 21:23
source share
10 answers

MQ, as Chad mentioned, is one way. There are also easier solutions:

  • A record extension that works much the same as a darcs record. It is distributed via mercury.
  • A Shelve extension that allows you to “defer” certain changes, allowing you to commit only a subset of your changes (those that are not deferred)
+34
May 13 '09 at 12:04
source share

If you use TortoiseHg 1.x for Windows, this feature is beautifully implemented directly from (no extensions are required).

  • Run the TortoiseHg Commit Tool.
  • Select the file for which you only want to commit a subset of your changes.
  • Click on the Hunk Preview tab in the preview panel.
  • Double-click or use the spacebar to toggle which changes should be included in commit.



For TortoiseHg 2.x, the Hunk Selection tab is now missing. In its place is the Shelve tool . It has a few more features than the old choice. These new features cost some added complexity.

enter image description here

Please note that when using this function, there is no need to explicitly enable the Mercurial Shelve extension. According to Steve Borjo (lead developer of TortoiseHg), in answer to another question from TortoiseHg : "We have a local copy of the shelf extension and direct access to it."




For TortoiseHg 2.7+, this functionality has been improved and updated. Now it is built directly into the Commit tool:

example of change selection in the commit tool

Please note that in the list of files on the left, which is indicated in the upper file, to indicate that it will be included, the second file is not installed because it will not be included, and the third Sample.txt file is full (Null checkbox), because in commit will only include changes from this file.

The change in Sample.txt that will be included is checked at the bottom of the image change selection. Changes that will be excluded will not be marked, and the diff view will be grayed out. Also note that the tool icon for the shelf is still available.

+37
Oct 05 '10 at 13:35 on
source share

The Mercurial Queues tutorial is terrible for this use case. All the examples that I saw suggest that you have yet to commit, and you are updating one patch. In most cases, this is not the case, and you have 2 or 3 commits that you want to insert or modify in some other way.

Let's say you have a story like this:

 ---O---O---A---B---C 

The first example - squash commits A, B and C. The first init mq:

 $ hg qinit 

Now we need to import the commits A, B, and C into the patch queue. Assume they are the last 3 commits. We can use the “-N” syntax to import them like this:

 $ hg qimport -r -3:-1 

This means that importing as patches of 3 patches returns to the last commit. You can check the status of these patches with hg qseries . It should show something like this:

 $ hg qseries 101.diff 102.diff 103.diff 

If the numbers 101, 102, and 103 correspond to the local revision numbers of commits A, B, and C. Now these corrections are applied, which means that the changes they describe are already in the working copy. You can get rid of working copy changes and remove them from the commit history by saving them only in patch form using hg qpop . You can say hg qpop; hg qpop hg qpop; hg qpop to swap C and B changes from the stack, or specify a patch for "pop to". In this case, it will be something like this:

 $ hg qpop 101.diff now at: 101.diff 

Now you have corrections for commits B and C in the patch queue, but they are not applied (their changes were "lost" - they exist only in the patch queue area). Now you can add these patches to the last, i.e. We create a new commit that is equivalent to the sum of the changes A + B + C.

 $ hg qfold -e 102.diff 103.diff 

This will show your editor so that you can change the commit message. By default, a message will be a concatenation of commit messages for changes A, B, and C, separated by asterisks. It's nice to note that hg qfold will fill in patches if you use bash and gain access to the hg-completion script. This leaves a story like this, where A + B + C is the only commit, which is a combination of 3 patches that interest us:

 ---O---O---A+B+C 

Another use case is if we have the same story as before, but we want to remove patch B and merge A + C. This is actually similar to the above. When you go to the qfold step, you simply add up the last commit, not the last 2 commits:

 $ hg qfold -e 103.diff 

This leaves the change for B in the patch queue, but it does not apply to the working copy, and its commit is not in the history. You can see this by doing:

 $ hg qunapplied 102.diff 

Now the story looks like where A + C is one commit that combines the changes of A and C:

 ---O---O---A+C 

The final use case might be that you only need to apply commit C. You would do this by running qimport as described above and you would pull out all the fixes you don't need:

 $ hg qpop -a 

The -a flag means turn off all patches. Now you can only apply the one you need:

 $ hg qpush 103.diff 

This leaves you with this story:

 ---O---O---C 

Once you are done with all this, you need to finish the job in line. This can be done with:

 $ hg qfinish -a 

So here we are. Now you can run hg push and do just what you want, or hg email patch in the mailing list.

+17
May 13 '09 at 20:35
source share

I feel like I'm missing something because no one suggested it.

The usual "hg commit" command can be used to selectively select what needs to be done (you do not need to commit all pending changes to the local working directory).

If you have such a set of changes:

 M ext-web/docroot/WEB-INF/liferay-display.xml M ext-web/docroot/WEB-INF/liferay-portlet-ext.xml M ext-web/docroot/WEB-INF/portlet-ext.xml 

You can commit only two of these changes with ...

 hg commit -m "partial commit of working dir changes" ext-web/docroot/WEB-INF/liferay-display.xml ext-web/docroot/WEB-INF/liferay-portlet-ext.xml 

Not super convenient from the command line, because you must manually enter files for selective fixing (against the check-box process of a graphical interface such as a turtle), but it is as simple as it is and does not require any extensions. And file globalization can probably help reduce typing (as it was above, both committed files unambiguously pass "liferay" in their path names.

+16
Dec 26 2018-11-12T00:
source share

You can use the extension that comes with Mercurial.

First you must include it in your ~/.hgrc file by adding it to the [extensions] section:

 [extensions] record= 

Then simply enter hg record instead of hg commit , and you can choose which changes will be fixed.

You can also use the crecord extension, which provides a more convenient interface for viewing and selecting changes. (However, it is not distributed with Mercurial, and I saw how it sometimes messes up the commit so that it is not completely error-free.)

+8
Jan 18 '12 at 11:44
source share

I believe Mercurial Queues fills this role for Mercurial. There is a pretty good tutorial related to it.

+4
May 12, '09 at 21:28
source share

Try the qct (Qt Commit Tool). It has a “select changes” feature that launches a three-way merge tool so you can revert individual changes. After you commit, the changes that you “unfastened” are returned.

+2
May 24 '09 at 10:51 p.m.
source share

I am using commit-patch . This is a script that allows you to edit diff before committing. This is really nice with Emacs diff-mode and vc-mode.

I used crecord in the past, but it has unicode-related errors (in fact, the extension of the record has errors that crecord depends on).

+2
Oct 07 2018-10-10
source share

Some time has passed. It seems the best option now is hg commit --interactive

+2
Feb 07 '17 at 7:28
source share

First you must forget everything you ever knew about the GUI and return to the command line. Next, from the command line, do the following:

hg stat> filelist.txt

This translates all of your modified files into a text file called filelist.txt

Next, edit your list of files to include only the files you want to commit.

Finally, complete the use of the sytnax file set:

hg commit "set: 'listfile: test.txt'"

-one
Apr 17 '14 at 19:37
source share



All Articles