The documentation is littered with mentions of "applied patches", i.e. in hg qfold, it says "Patches must not yet be applied."
How do I apply a patch, and how do I know when a patch is applied? This concept doesn't seem to appear in the output of hg qser or its --help.
Once I left the --help behind, I was able to find this:
hg qapplied
Ref: MqTutorial.
Related
I'd like to use bookmarks in Mercurial to share new features with other developers. I have followed the basic workflow as they appear here or here. In short:
$ hg bookmark main
$ hg bookmark feature
$ hg update feature
$ hg commit -m "changes"
$ hg push -B feature
My main problem is that at this point my changes are not separate from the default branch, and if someone else does
$ hg pull
$ hg update
in their working directory, they get my changes, too, which is not intended - I would like them to do hg update feature to get them.
I figure if I then commit something (an empty commit maybe) to main and push that as well, all is well and feature appears separate. But is there a better way achieving the same result?
Mercurial knows the special bookmark #. Attach that to a commit which is updated to by default.
See also the wiki, section 5.
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
$ hg pull
Password:
pulling from ssh://foo#bar.com:22//home/usr/xxx/repo
searching for changes
adding changesets
adding manifests
adding file changes
It then keep showing the above for 10+ min. Is there a way to tell the progress and whether it's still live or already dead?
Use the Progress extension by adding the following to your HGRC:
[extensions]
progress =
and/or use the verbose option:
hg pull -v
There is a related question on StackOverflow that may also be useful to you.
As for your followup question: if Mercurial is tracking a file (that is, if you hg add and later hg commit subdir1/subsubdir1/foobar.c) then it wont ignore it. So .hgignore can only help you clean up the entries listed with ? (the unknown files) in hg status — it wont have any effect on tracked files.
The progress extension is your friend. You can also add the -v/--verbose and --debug switches to hg pull see more data.
In Git it is easy, because remote/branch is pointing to a different commit than branch. How to do it with Mercurial?
If you mean seeing what's different between your local repo and the one you're pushing to, try
hg outgoing
Since Mercurial 2.1, there is also a purely local solution: phases. The draft phase is probably what you are looking for. For details, refer to:
https://www.mercurial-scm.org/wiki/Phases
You may find hg phase <rev> and hg log -r "draft()" interesting.
There is an remotebranch extension that will give you a Git-like setup. It tracks the remote heads for the repositories listed in the [paths] and exposes them as tags named <path>/<branch>. This lets you run
$ hg diff -r foo/default
to see what has changed since the default branch in the foo repository. There is also new revset keywords that let you do things like
$ hg log -r "not pushed()"
to get what
$ hg outgoing
would do, but without any network traffic.
What's the command line call to show all revisions in the draft phase?
hg log --style phases
That will display the log + the phase, since Mercurial 2.7 (2013-08-01).
I'd just use hg outgoing as others are suggesting, but hg summary will tell you too. It may require the --remote option to have it check the remote default server.
If you need to select the changesets for further processing, then you can use the outgoing revset predicate. This lets you re-implement hg outgoing as
hg log -r "outgoing()"
but the real benefit is that you can use this in other contexts, such as
hg strip "outgoing()"
I've recently started working with MQ as I like the idea of working on isolated patches and committing without affecting the repo until the changeset is refined enough. Before that, I used to work with Mercurial's shelves extension, but found it a bit unstable. What I'm still trying to figure out in MQ is how to keep patches separate from each other and apply them in no particular order, and across different branches. Here's my normal flow -
1. Start working on a new patch:
hg qnew fix-bug-1234 -m "fix bug 1234"
# do some work
hg qrefresh
2. Get a new feature/bug to work on:
hg qpop fix-bug-1234
hg qnew some-feature -m "implement feature X"
# some work on feature X (perhaps in a different branch)
hg qrefresh
3. At this point, I'd like to get back to working on bugfix, and put aside the feature work. I thought it's as simple as:
hg qpop some-feature
hg qpush fix-bug-1234
# wrap up bug fix
hg qfinish fix-bug-1234
# get back to work on feature
However, MQ seems to always use the latest patch created in the series, and apply it regardless of the qpop/qpush command I'm using. I should note that the files I work on are completely separate as well (though they can sometimes be the same).
Am I missing something here? Should I be using hg qqueue for this? Thanks.
You could use guards. They allow you to maintain an ordering of patches without rearranging your series file, and selectively apply only a subset of patches, still in a stack-ordered fashion.
An example in your case would be:
hg qnew bugfix
# ..hack hack..
hg qrefresh
# want to switch over to working on some feature now
hg qpop
hg qnew feature
# ..hack hack..
hg qrefresh
At this point, you're in a situation where patch feature comes before bugfix in your stack. Now you can use guards to select one or the other, and switch between the two:
hg qpop -a
hg qguard feature +featureguard
hg qguard bugfix +bugfixguard
If you want to work on feature:
hg qselect featureguard
hg qpush
applying feature
now at: feature
If you want to work on bugfix:
hg qpop -a
hg qselect bugfixguard
hg qpush
applying bugfix
now at: bugfix
Note that since you selected the positive guard bugfixguard, MQ leap-frogged over feature (because it's positive guard was different than the one selected) and applied the patch bugfix instead (which did match the selected guard).
Some useful tools when working with guards are hg qseries -v, which will display a G instead of the usual U for a guarded, unapplied patch, and hg qselect -l which will display the guards associated with each patch.
Execute hg qpop -a to remove all patches from the stack
Execute hg qpush --move some-patch to apply "some-patch" without applying whatever other patches may be before it in the patch stack
No, you aren't missing anything. The mq extension does make a pretty strong assumption that patch queues are linear. If you're going to be creating multi-patch features/fixes then qqueue would work… But if your features/fixes are just single patches and you want to be able to apply one with out applying the others, it might be easier to just re-arrange .hg/patches/series (which stores the order that patches will be applied).
I do this (and hand-editing patches) enough that I've got a shell alias:
alias viq='vim $(hg root)/.hg/patches/series'
Alternately, if you don't mind applying multiple patches at the same time, you could use qgoto:
$ hg qser
0 U bug-1234
1 U feature-4321
$ hg qgoto feature-4321
$ hg qser
0 A bug-1234
1 A feature-4321