git bisect run conveniently bisects a given range of revisions with a script run on each revision whose exit status is used to determine whether it is good, bad or broken.
hg bisect does not seem to offer this automatic ability. I need to manually mark each revision as either good or bad. Is there an extension or script that provides a functionality comparable to git bisect run for mercurial?
Read hg help bisect by eyes. Note -c CMD option. Use it
Related
I want to commit only some of the modifications I made to my files and my preferred way to do this is to shelve/stash away the changes I don't want to commit. This allows me to test the changes I will commit before actually commiting them.
The problem I am having is that when I use the "shelve" tool in tortoisehg I can't find any way to split a chunk into two smaller chunks. For example, I have a chunk that looks like this:
## -1,1 +1,2 ##
-hallo world
+hello world
+something else
I would like to shelve away the "something else" so I can commit just the "hallo->hello" fix. However, since tortoisehg is seeing this a single chunk I can either shelve both or none of the changes.
I also tried using the shelve extension via the command line but from what I understood from the documentation it does not offer the feature to shelve away only parts of the files.
You can accomplish your goal from the command line. There are interactive versions of hg commit, hg revert, and hg shelve, and they have low-level options to hack a patch together if needed; you can use them with the -i (or --interactive) command line option.
This means that you can build up a commit with hg commit -i and hg commit --amend -i. If you have the evolve extension installed, you can use hg uncommit to pull changes out of the commit again; if not, you can use hg revert -r .~1 or hg revert -i -r .~1 a file and use hg commit --amend -i again to fix it up.
In order to select individual lines from a patch, you have two options. You can use e to edit the patch (but see below for a more convenient option).
You can then use hg shelve to shelve the remaining changes.
You can in principle also do this with hg shelve -i, however, there's a big caveat; if you edit patches for hg shelve -i, then Mercurial's merge mechanism will get confused and not process the change cleanly, but dump you in a merge tool in order to resolve this apparent conflict (which means lots of extra work to resolve it). Hence why I strongly recommend using hg commit -i and hg commit --amend -i if you want to manipulate things at the line level (hg shelve -i works fine if you don't edit the patches).
For added convenience (that prevents you from editing patches), you can also enable the experimental crecord option by adding the following to your hgrc file:
[experimental]
crecord = true
This will enable a terminal-based hunk editor for hg commit -i, hg revert -i, and hg shelve -i that allows you to select individual lines and hunks (internally, that works roughly the same way as editing patches). Use the ? key to get help in that editor; use f to unfold/fold individual hunks and the space key to select hunks/lines.
Note that line-based selection for this tool in conjunction with hg shelve -i comes with the same caveats as editing patches; i.e. use hg commit -i and hg commit --amend -i instead if you want to do line-based selection. Also, line-based selection for hg revert -i will still revert the entire hunk. (There's a reason why this option is still marked as experimental.)
I don't know a command to do this, but if you are using tortoiseHg, you can do that by selecting modified sections (checkboxes) in the commit preview area.
See Mercurial cherry picking changes for commit
mq, which I like a lot, but which I understand is being deprecated in favor of changeset evolution, provides a command hg qdiff that shows the combination of the last-saved patch mixed with the current working directory diffs. I.e., it shows what will be the content of the complete patch if I enter hg commit --amend right now.
Is there a way to show the combined diff like that in base (non-mq) mercurial?
I realized the answer as I prepared to submit the question: hg diff with respect to the parent of the current change:
hg diff -r '.^'
I want to commit only some of the modifications I made to my files and my preferred way to do this is to shelve/stash away the changes I don't want to commit. This allows me to test the changes I will commit before actually commiting them.
The problem I am having is that when I use the "shelve" tool in tortoisehg I can't find any way to split a chunk into two smaller chunks. For example, I have a chunk that looks like this:
## -1,1 +1,2 ##
-hallo world
+hello world
+something else
I would like to shelve away the "something else" so I can commit just the "hallo->hello" fix. However, since tortoisehg is seeing this a single chunk I can either shelve both or none of the changes.
I also tried using the shelve extension via the command line but from what I understood from the documentation it does not offer the feature to shelve away only parts of the files.
You can accomplish your goal from the command line. There are interactive versions of hg commit, hg revert, and hg shelve, and they have low-level options to hack a patch together if needed; you can use them with the -i (or --interactive) command line option.
This means that you can build up a commit with hg commit -i and hg commit --amend -i. If you have the evolve extension installed, you can use hg uncommit to pull changes out of the commit again; if not, you can use hg revert -r .~1 or hg revert -i -r .~1 a file and use hg commit --amend -i again to fix it up.
In order to select individual lines from a patch, you have two options. You can use e to edit the patch (but see below for a more convenient option).
You can then use hg shelve to shelve the remaining changes.
You can in principle also do this with hg shelve -i, however, there's a big caveat; if you edit patches for hg shelve -i, then Mercurial's merge mechanism will get confused and not process the change cleanly, but dump you in a merge tool in order to resolve this apparent conflict (which means lots of extra work to resolve it). Hence why I strongly recommend using hg commit -i and hg commit --amend -i if you want to manipulate things at the line level (hg shelve -i works fine if you don't edit the patches).
For added convenience (that prevents you from editing patches), you can also enable the experimental crecord option by adding the following to your hgrc file:
[experimental]
crecord = true
This will enable a terminal-based hunk editor for hg commit -i, hg revert -i, and hg shelve -i that allows you to select individual lines and hunks (internally, that works roughly the same way as editing patches). Use the ? key to get help in that editor; use f to unfold/fold individual hunks and the space key to select hunks/lines.
Note that line-based selection for this tool in conjunction with hg shelve -i comes with the same caveats as editing patches; i.e. use hg commit -i and hg commit --amend -i instead if you want to do line-based selection. Also, line-based selection for hg revert -i will still revert the entire hunk. (There's a reason why this option is still marked as experimental.)
I don't know a command to do this, but if you are using tortoiseHg, you can do that by selecting modified sections (checkboxes) in the commit preview area.
See Mercurial cherry picking changes for commit
How can I see, if the changeset has already been grafted between branchX and default?
I know, hg graft checks this for me, there I can't graft twice, but I want to list all changesets, which were not grafted between branchX and default.
Thanks in advance for your answers.
This information is stored in the so-called "extra" dictionary inside the grafted changeset. This is a simple key-value mapping that you can see with hg log --debug.
The information is unfortunately not exposed as a revset predicate yet, so you'll have to do it the old-fashioned way: start with
$ hg --debug log -b branchX
to get the changesets on branchX. Then grep or otherwise search for lines matching
extra: source=[0-9a-f]{40}
You could use the Mercurial bindings if you want a more high-level access. There are libraries for Java, Python, and Scala at the moment.
You can use a revset to do this if you have Mercurial 2.3 or newer:
$ hg log -r "destination()"
to get a list of all of the changesets that are the destinations for grafts. You can also do:
$ hg log -r "origin()"
to get a list of all changesets that are graft origins. These revsets both take another revset as arguments, so you can use the full power of composable revsets to drill down in your search.
I'd like a quick way to know how many conflicts I will need to merge manually. Is this built-in? Or is there an existing tool to use as the merger to just count this?
There's no built in predictor command, as it would take as much effort computationally as doing the merge. However, if you do a hg --config ui.merge=internal:fail merge it will exit immediately and you can do a hg resolve --list.
That will show you what you're in for, and you can either continue with hg resolve --all or give up with hg update -C .