hg revert -r 4 -I *.aspx
isn't working for me. Any help? And no, I don't want to use TortoiseHG.
Try hg revert -r 4 -I **/*.aspx from the root directory of the repository. The **.aspx matches any file in any subdirectory in the repository whereas *.aspx only matches them in the current directory.
See hg help patterns for more information, which I've just noticed shows a regexp-based alternative:
hg revert re:.*\.aspx$
Related
I've looked for that in the manual, but I can't generate a patch for the last commit.
I tried
hg qnew patch_name
but it does only file with
# HG changeset patch
# Parent a6a8e225d16ff5970a8926ee8d24272a1c099f9c
I also tried
hg export tip
but it doesn't do anything. I committed the changes exactly.
How to generate a patch file with the last commit in?
The command to do this is export:
$ hg export -o FILE -r REV
It doesn't require redirection and will thus work correctly on any platform/shell.
Your hg export tip is the best way to do it, and the hg diff and hg log based answers are just lesser versions of the same. What exactly do you see/get when you type hg export tip? What does the output of hg log -p -r tip show?
The changeset tip is just means "the changeset that most recently arrived in my repository" which isn't as useful a concept as you might think, since hg pull and hg tag all create changesets too. If you really want the last thing you committed you'll need a more precise revspec.
Like so:
hg diff -r tip > tip.patch
You can use this command:
hg log -r tip -p > tip.patch
this will generate a patch for just that revision.
If you want to convert the latest commit to a patch file, use
hg qimport -r tip
This will replace the topmost regular commit with an applied MQ patch file.
To generate patches using "mq extensions" in mercurial, you can follow the below given steps. This will create a patch using mercurial:
1) Enabling mq extensions: Add the following lines to your hgrc file and save it.
[extensions]
mq =
2) Creating a patch using mq extensions: To create a patch using mq extensions you can do the following.
hg qnew -e -m "comment you want to enter" bug_name.patch
In the above command, -e flag is for editing the patch and -m flag is for adding a message to the patch.
3) Updating the patch: For updating the patch, you can use the following command when a patch is already applied.
hg qrefresh
I need to revert all files in a working directory that match the name "test" anywhere inside the filename.
Is it possible to revert all this 3 files by using hg revert -I syntax:
/includes/atest.txt
/test.txt
/test/test/test.txt
It should work (I cannot test it right now) with the following syntax, according to issue 1697:
Windows:
hg revert "glob:*test.*"
# or
hg revert -I "*test.*" --all
Unix:
hg revert 'glob:*test.*'
hg revert -I '*test.*'
(Note the simple quotes for Unix)
As noted by Blaise in the comments
On macOS/Unix, you need to use ** if you want to match files in any directory, e.g.
hg revert -I '**/*test.*'
To expand on the given answer above
You can include all files in subdirectories in your revert by using the following syntax:
Windows:
hg revert "glob:**\*test.*"
And I assume Unix would be:
hg revert 'glob:**/*test.*'
I have a large commit of many files on one branch, I need to transfer the modifications of a single file in that changeset to another branch. How can I do this? I am mostly using TortoiseHg but commandline solutions are also fine.
If I go to the changeset in TortoiseHg and select the file I can see the diffs I want to transfer, but not a way to actually apply them.
You can get the patch for just that file using:
hg log -r THEREVISIONWITHLOTSOFCHANGES -p -I path/to/justthatfile > justthatfile.patch
which you can then import on whatever branch you want by doing:
hg update anotherbranch
hg import --no-commit justthatfile.patch
hg commit
The most basic solution is to dump the patch of the file, apply it to the current working revision, and commit it (assuming you're at the root of the repository):
$ hg up <revision-to-apply-the-patch-to>
$ hg diff -c <revision-containing-the-patch> <files-to-include> | patch -p0
$ hg ci -m "Transplanting selected changes from <revision-contain...>"
The drawback of this method is that it isn't very obvious what you've done from a revision history perspective. A good commit message helps here, but the history graph gives no hint about the process of transplanting some changes. In that case merging and reverting may be a better solution:
$ hg up <revision-to-apply-the-patch-to>
$ hg merge -r <revision-containing-the-patch>
$ hg revert --no-backup <files-to-exclude>
$ hg ci -m "Merge in changes of <files-to-include>"
Probably there are more solutions to do this -- these two came to my mind first.
Using Mercurial, say if I do an hg pull and hg up and now the local repo and working directory are both up to date.
What if I commit often, say 1 day later, and then 2 days later, and want to diff with the revision as of right now?
Otherwise, the diff is always comparing to the previous committed version.
I can use pencil and paper and write down the revision number right now, say, 4117, and then 1 day later, 2 days later, and any time before I am sure and push to the remote central repo, do an
hg vdiff -r 4117
(either using vdiff or diff). But instead of remembering this "magic number" 4117, is there a way to make Mercurial somehow remember this number? That way, hg vdiff is to see the difference between minor changes against committed code, but there is a diff that shows all changes before pushing to the remote repo.
(or, if there is command that shows the revision number since your last pull, which should also show 4117, so on bash we can do something like hg vdiff -r `hg --what-is-last-pull` )
Update: does hg out --patch show the diff of what would be pushed to the remote repo? If so, maybe it serves the purpose without caring the "magic number". But how to show the patch diff using kdiff3 or any other diff tools? Also, it seems we can do hg out and if we see 4118, 4119, 4120, then we know if we do hg vdiff -r ___ we should use (4118 - 1) which is 4117.
Update 2: actually, hg out --patch shows the diff between local repo and the remote repo, so it is close, but not exactly the same as the diff between working directory and the local or remote repo.
If you want to mark a revision you can use bookmarks extensions. It is shipped with mercurial. Documentationis available here
In your case,
hg pull -u
hg bookmarks lastpull
..hack..hack..
hg ci -m new-hack
hg diff -r lastpull:tip
hg bookmarks -d lastpull
Do it with multiple clones. When you clone from the remote repo initially use clone -U to create a clone that has no working directory files at all. Then clone again locally, for example:
$ hg clone my-local-clone-with-no-working-files my-working-clone
Do your commits and work in my-working-clone and then at any time you can check the tip in my-local-clone-with-no-working-files to see what the last thing you pulled from the server was. If you want to get fancy you could create a shell alias for:
hg diff -r $(hg -R $(hg root)/../my-local-clone-with-no-working-files id -i -r tip)
which will compare the working directory of the repo in which you run it (my-working-clone) with the tip of whatever you last pulled from the server.
It's worth nothing that this takes no extra disk space because local clones use hardlinks under the covers the the my-local-clone-with-no-working-files has no working directory files.
You can replace pen and paper with a local tag: hg tag -l -r <revision number on paper> tagname. Notice the -l, which makes the tag local, which means it does not get transferred by push and pull. You can also remove this tag by hg tag -l --remove tagname.
I have a repo located at x:/projects/repo1. The working directory has been emptied using hg update null. I want to extract the latest version of some files from there to a local directory.
I tried this:
x:\projects\repo1> hg cat -o c:\sql\%s scripts\*.sql -r tip
I get this error:
scripts\*.sql: No such file in rev 14f07c26178b
The same command works fine if the working directory is not empty. Is there a good reason why this does not work? Or do you know another way of extract some files from there to a local directory?
The hg cat command is for single files. If you want multiple files use the hg archive command, which makes zipfiles or directories full of files. Here's your command:
x:\projects\repo1> hg archive --include scripts\*.sql -r tip c:\sql
It seems that hg cat doesn't support wildcard symbols in paths. So you should use the full file name:
hg cat -r tip scripts/foo.sql
When your working copy is up to date with the tip revision, your shell does wildcard substitution for you.
The hg manifest command also might be helpful for getting tracked file listings.
This answer is to your comment on Andrey's answer:
hg manifest takes a --rev argument that you can use to see the list of all files in your repository:
hg manifest --rev tip
To get the list of files matching a pattern at the tip, use:
hg stat --all --include *.sql --rev tip --no-status
hg stat -A -I *.sql --rev tip -n # using abbreviations.
From there you could redirect the output to a file and edit each line into a hg cat command like in your original question. It appears (to me, at least, having done some experimentation) that hg cat uses the contents of the working directory -- rather than the contents of the repository at the revision specified -- for glob-matching, so once you know the exact name of the file, you can hg cat it at any revision.