I'm looking for the Mercurial equivalent of git commit --allow-empty for testing purposes.
Can't be done. There doesn't have to be a change to a source file, but you have to have changes something, be it file permissions, branch name, tag, or something.
You say "for testing purposes". If that's the case I usually just use
echo another line >> README ; hg commit -m 'added another line'
I can hit up-arrow enter on that plenty fast.
I think the best solution I've found is:
touch foo
hg add foo
hg commit -m 'Empty commit'
hg rm foo
hg commit --amend
Works with MQ. Make a MQ changeset with some dummy change, then revert the change and refresh (hg qref) the patch. Voila.
Related
I have a commit onto which I have amended some files. Some of these files that were part of the amend I do not want in this commit. Is there a way in Mercurial to remove certain files from the commit without losing the changes I have made to them? Thank you.
Steps:
Made some changes
hg commit -m
Made some more changes (some of these file accidentally amended)
hg amend
Try out:
hg forget somefile.txt
hg commit --amend
If the file was new (i.e. you had used hg add).
If that file already existed try:
cp somefile.txt somefile.txt.bak
hg revert somefile.txt --rev .~1
hg commit --amend
Which is basically telling mercurial to revert the file (somefile.txt) back to the state it was one revision ago (--rev .~1).
Just make sure to back up the file you are reverting before entering the command so that you do not lose your changes. I was under the impression mercurial does this automatically for you, but after testing it quickly I'm not so sure.
hg uncommit somefile.txt does exactly this for me.
Like plain git reset, it removes the change from the commit but leaves the file contents unchanged, so now hg diff shows the change you just uncommitted.
The uncommit command claims to come from the uncommit extension, but may actually be coming from the evolve extension, I admit I'm not 100% sure!
Is it possible to do a commit without any changes in the current repository with Mercurial, like git's --allow-empty?
Trick I read somewhere:
touch tmp
hg add tmp
hg commit -m "tmp"
hg rm tmp
hg commit --amend -m "Real commit message"
Unfortunately it doesn't survive rebasing (and maybe other operations).
The answer from #Thomas above is correct but doesn't fully explain how to modify the file content of a commit.
A simple method to use this feature to force an commit empty is as follows:
Add a new file (say, Dummy.txt) and commit.
hg forget Dummy.txt
hg commit --amend
This will remove Dummy.txt from the previous commit, leaving it empty.
With amend you can change the user, date, commit message and files content:
hg commit -m"new message" -d"$(date --rfc-2822)" -u"new user" --amend
These are probably all the reasons why you would want to commit an empty changeset.
I issued hg qnew without realizing that it includes any outstanding changes into the patch. I'd like to back that out and pick only specific changes using hg qrecord. How can I undo qnew?
Your answer definitely works — with newer Mercurial's you can use hg strip --keep to avoid doing the import step:
$ hg strip --keep .
$ hg qdelete patch-name
The --keep flag makes strip ignore the working copy while working, that is, it deletes the commit (like hg qpop would do) but it doesn't undo the changes to the files. After stripping you still have the patch in your series (unapplied) and you can then delete it.
I've found an anwer here:
hg qpop
hg import --no-commit .hg/patches/patch-name
hg qdelete patch-name
Please add a better way, if you know.
Update: Based on Aldo's answer, there is another way:
hg qnew test
# We can undo the above qnew as:
hg qrefresh -X '*'
hg qpop -f
hg qdelete test
If you just want to undo the latest qnew retaining all your local changes, one option is:
qcrefresh 123
hg qpop -f
hg qdelete <name of the patch>
Notice that 123 is just a random string: you are telling mercurial to only include the (hopefully nonexistsnt) 123 file in the current patch.
Newer versions of Mercurial When you issue will issue a warning about the fact 123 file does not exist, but this is exactly what we want here.
If you want to retain some of the changes in the current path, you can use the qcrefresh command from the crecord extension, which allows to graphically select the changes to be included in the current patch. You need to download it from Bitbucket, extract the archive and configure it in .hgrc:
[extensions]
crecord = <path/to/crecord/package>
I have been making some changes to my working directory, and noticed that I have accidentally been working on the wrong branch. I have not committed anything yet, and I would like my next commit to go against another branch. What is the best way to do this?
The Shelve extension can give you grief, and this can be done entirely with Mercurial commands. Krtek almost had it but he used export instead of diff. Try this:
hg diff --git > ~/saved-work.patch
hg update --clean desiredbranch
hg import --no-commit ~/saved-work.patch
You should be able to just hg up otherbranch. It is important that you do not use the --clean option to hg up, either directly or via an alias as that will discard your uncommitted changes.
Another option is to use one of the extensions that provides hg shelve. The process would then be:
$ hg shelve --all
$ hg up otherbranch
$ hg unshelve
That will create a patch of your changes within the .hg directory, returning your working directory to a clean state, switch to the 'otherbranch', and then apply the saved patch.
I don't know if it is the best solution, but you can follow these steps :
1° hg diff --git > modifications.patch
2° hg update -C the_right_branch
3° hg patch modifications.patch
Maybe it's better to copy modifications.patch somewhere safe, just in case.
edit: update with diff instead of export. Thanks to the commenters.
is this possible with Mercurial? and which Version Control system can do this besides Clearcase?
David is correct that you can't have a branch that exists on only a single file, but it's worth pointing out that people often have branches that alter only a single file. Since the branch metadata is stored in the changeset, and since the changeset contains only a delta (change), having a branch that alters only a single files is nearly instantanous to create, update, commit, and merge, plus it takes up almost no space on disk.
Resultingly, it's a very common way to handle per-customer configurations. Keep the tiny change for them in a branch, and merge from main, where development happened, into that branch, whenever you want to update their deployment.
How you could use MQ:
$ hg qnew -m "Changes for client0" client0
... change the file ...
$ hg qref # update the client0 patch with the changes
$ hg qpop # pop the changes off the queue stack
... develop like normal ...
... client0 asks for a build ...
$ hg qpu # apply client0's patch
$ make release
$ hg qpop
It would get a bit finicky if you've got to deal with a lot of clients… But it may be worth considering.
The other thing you could do, of course, is just commit a bunch of .diff files:
... make changes for client 0 ...
$ hg diff > client0.diff
$ hg revert --all
$ hg add client0.diff
$ hg ci -m "Adding client0 changes"
... develop ...
... client0 asks for a build ...
$ patch -p1 < client0.diff
$ make release
$ hg revert --all
No, it's not possible. A branch in Mercurial is a snapshot of the entire repository state.
You could do it with CVS, though, as CVS tracks changes on a per-file basis :)