I am running a rebase on a set of changes in Hg. Occasionally it comes up with a message that says something like local changed somefile.cs which remote deleted. use (c)hanged version or (d)elete?
I assume that when I am rebasing I want to follow what the remote is doing, so I have been deleting. If this is incorrect, someone stop me.
However, here is the big thing? I've noticed that if I just press Enter it seems to move on. However I have no idea what it is defaulting to. Does anyone know?
The default is to use the (c)hanged version. Rebase uses the merge logic for this operation.
There is no documentation of this default choice, but it is decided here:
216 if repo.ui.promptchoice(
217 _(" local changed %s which remote deleted\n"
218 "use (c)hanged version or (d)elete?") % f,
219 (_("&Changed"), _("&Delete")), 0):
220 act("prompt delete", "r", f)
221 else:
222 act("prompt keep", "a", f)
There does not appear to be a way to automatically decide which option is selected.
Related
I'm trying to write some scripts for doing some simple housekeeping tasks in mercurial and one of the things I frequently need to do is check if the working set is "empty" (depending on context, that could mean untracked files or modified tracked files).
The hg status command exits with exit status 0 unless there was an internal error, in which case it exits with exit status 255.
If a few of my scripts, I'm doing something silly like capturing the output of the hg status command and checking whether it's empty or not.
In other cases I'm checking the exit status of hg id -i | grep -qvF + to check whether there are dirty tracked files.
Both of these seem a little brittle. Are there dedicated subcommands for "querying" the repository to see if there are "untracked files" or "dirty tracked files" or "removed files" or various other interesting things in the working set?
hg status is the command to check for modifications of the working directory with respect to the checked-out revision - thus you are doing the right thing.
You can get away with exclusively using hg status. Using the --mard (or --modified --added --removed --deleted) flags will yield empty if the tracked files didn't change. And using -u or --unknown will show files which are neither ignored nor tracked - and empty output should always indicate no changes to tracked files nor any non-ignored files (but there might be new files which match one of the ignore patterns).
The output format of these commands (at least in the English original, thus LC_ALL=C hg status) is treated by mercurial as API, thus you should be able to rely on it.
Depending on your actual use-case you might want to look at the mercurial command server - but for a script which runs occasionally it might be quite over the top.
test -z "$(hg status -mard --template x)" && echo clean || echo dirty
Seems to work
I suddenly have a few files that show as modified, but KDiff says they are binary equal. Reverting and discarding those changes does nothing.
Somehow, the eol extension is enabled and when I try to disable it, I can't view that one repo's Working Directory in TortoiseHg. An error appears:
[Error 6] The handle is invalid
When using the command line hg status, this error appears:
'cleverencode:' is not recognized as an internal or external command,
operable program or batch file.
When using hg revert myfile, .orig files are generated but the files still appear as modified and the same error from above appears.
When updating to a previous commit, a whole lot of other files get in the same situation like those few I have now.
If necessary, I can throw away this clone and make a new clone, but it would be nice if this can be resolved without doing so.
Was able to solve it.
My global mercurial.ini had some lines with cleverencode in them. After removing those, the issue has disappeared. Enabling/disabling the eol extension also doesn't seem to cause any issues any more.
I suspect the troublemaker was Atlassian's SourceTree, I had installed an update yesterday and it asked if automatic line ending handling should be enabled. I'm quite sure I unchecked it, regardless, it seems to have mixed eol config with win32text config.
See also: [SRCTREEWIN-708] Possible error with Mercurial line ending handling configuration - Atlassian JIRA
I found that the cleverencode did not work for me -- I didn't have it in my mercurial.ini. My case was also a binary file that mysteriously got marked as modified and would not go away with revert, clean, etc...
I did some poking around and fixed it: there's a repo/.hg/largefiles directory. I believe mercurial keeps this as a local cache of binary files in order to revert back changes. In this directory you'll see a bunch of file names in hex. In TortoiseHg "browse" your binary file causing the problem. It'll show you the hex code corresponding to your binary. Find that file in the largefiles directory and delete it.
You should now be able to revert the file back to unchanged. I think mercurial uses the largefiles version to revert first. Then, when this version doesn't match the repo version it gets marked as modified (in my case my binary somehow got truncated to 0 length) and will never go away.
You can also just delete the largefiles dir altogether if you can't match the hex name. It will get recreated as needed. I think the only repercussion is that it's take longer to do some binary file operations since it will have to go to the server.
I'm using Google code and Mercurial for a small project javaclass-rb. I cloned the repository using HTTPS. My .hg/hgrc contains
[paths]
default = https://javaclass-rb.googlecode.com/hg/
From time to time Google Code has a different fingerprint (most likely to the clustering of service). When I want to pull (with hg 1.8.4), I get
E:\Develop\JavaClass>hg pull -u
abort: invalid certificate for javaclass-rb.googlecode.com with fingerprint 28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27
Then I have to change my ~/.hgrc file and update the hostfingerprintssection to contain the new fingerprint:
[hostfingerprints]
javaclass-rb.googlecode.com = 28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27
Then everything works fine again, until next time. Now this gets annoying as I did it ten times already, approx. once a month, and have to do it on several machines (desktop, laptop, work pc etc.)...
34:4b:90:e7:e3:36:81:0d:52:1f:10:c0:4c:98:66:90:4a:9e:05:c9
6e:a8:09:6a:42:60:d7:81:f7:04:b8:0f:5d:1e:ac:b3:58:db:7e:da
89:6d:fb:e5:4a:7e:72:91:db:0b:ee:72:9f:60:a7:29:65:fd:e1:10
da:b3:df:aa:55:73:ac:65:04:70:78:8e:ed:dd:a9:be:40:a8:64:81
a9:be:c0:4a:da:1c:eb:4c:31:9d:78:27:48:99:f4:9c:9a:e8:53:c8
ed:19:7c:b9:a3:48:27:93:72:74:43:db:26:40:af:e0:7a:90:1c:97
28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27
Do you know a way to configure Mercurial to ignore the fingerprints or some other way I get rid of this annoyance?
Answer
tonfa led me on the right track. Mercurial is checking also OS certificates. Originally I had to fall back to fingerprints because Googlecode certiicate is not valid for subdomains:
The certificate is only valid for the following names:
*.googlecode.com , *.u.googlecode.com , googlecode.com , *.codespot.com , *.googlesource.com , googlesource.com
1) I removed the fingerprints from .hgrc, then the top domain javaclass-rb.googlecode.com worked again, because it is matched by *.googlecode.com.
2) Subdomains have to be cloned with another name, see Google support.
Ignoring the fingerprints and not verifying the signature is a very bad idea.
You should follow the instructions at https://www.mercurial-scm.org/wiki/CACertificates (basically a recent version of TortoiseHg should be already correctly configured).
Try the command hg pull --insecure.
I have this accurev issue where almost ALL source-controlled dirs under my workspace are shown as "external" eventhough they are not --accurev stat confirms the same externality. Accurev update has not solved the problem: just pulls down the entire source tree everytime, indicating that the existing file-structure is external to accurev. I have poked around accurev manauals but, have not seen anything specifics on what the problem(s) might be. Any help is appreciated.
In the past, when this has happened to me, deleting everything in the external view and repopulating the workspace fixed this problem.
I usually just delete from the GUI if possible. Then open a command prompt, browse to the root directory of the workspace in question and run:
accurev pop -R *
You may have had an "accurev update" fail for some reason, which has left the workspace out of sync. To find out if this was indeed the root cause, you can run "accurev show -fx wspaces" from a command prompt and compare the Target_trans and Trans values. If they are different, you have an inconsistent workspace.
To resolve this, you can run "accurev update -9" which will force the update level to the appropriate transaction. Subsequently you can delete all external files, as Josh indicated, and re-populate them. The command for this would be "accurev pop -R ."
Hope this helps...
I know this is an old question, but I just had this issue.
Updating my workspace with "Timestamp Optimization" unchecked resolved the problem.
I have a personal Mercurial repository tracking some changes I am working on. I'd like to share these changes with a collaborator, however they don't have/can't get Mercurial, so I need to send the entire file set and the collaborator will merge on their end. I am looking for a way to extract the "tip" version of the subset of files that were modified between two revision numbers. Is there a way to easily do this in Mercurial?
Adding a bounty - This is still a pain for us. We often work with internal "customers" who take our source code releases as a .zip, and testing a small fix is easier to distribute as a .zip overlay than as a patch (since we often don't know the state of their files).
The best case scenario is to put the proper pressure on these folks to get Mercurial, but barring that, a patch is probably better than a zipped set of files, since the patch will track deletes and renames. If you still want a zip file, I've written a short script that makes a zip file:
import os, subprocess, sys
from zipfile import ZipFile, ZIP_DEFLATED
def main(revfrom, revto, destination, *args):
root, err = getoutput("hg root")
if "no Merurial repository" in err:
print "This script must be run from within an Hg repository"
return
root = root.strip()
filelist, _ = getoutput("hg status --rev %s:%s" % (revfrom, revto))
paths = []
for line in filelist.split('\n'):
try:
(status, path) = line.split(' ', 1)
except ValueError:
continue
if status != 'D':
paths.append(path)
if len(paths) < 1:
print "No changed files could be found."
return
z = ZipFile(destination, "w", ZIP_DEFLATED)
os.chdir(root)
for path in paths:
z.write(path)
z.close()
print "Done."
def getoutput(cmd):
p = subprocess.Popen(cmd.split(), stdout=subprocess.PIPE, stderr=subprocess.PIPE)
return p.communicate()
if __name__ == '__main__':
main(*sys.argv[1:])
The usage would be nameofscript.py fromrevision torevision destination. E.g., nameofscript.py 45 51 c:\updates.zip
Sorry about the poor command line interface, but hey the script only took 25 minutes to write.
Note: this should be run from a working directory within a repository.
Well. hg export $base:tip > patch.diff will produce a standard patch file, readable by most tools around.
In particular, the GNU patch command can apply the whole patch against the previous files. Isn't it enough? I dont see why you would need the set of files: to me, applying a patch seems easier than extracting files from a zip and copying them to the right place. Plus, if your collaborator has local changes, you will overwrite them. You're not using a Version Control tool to bluntly force the other person to merge manually the changes, right? Let patch deal with that, honestly :)
In UNIX this can be done with:
hg status --rev 1 --rev 2 -m -a -n | xargs zip changes.zip
I also contributed an extension, see the hgexportfiles extension on bitbucket for more info. The export files extension works on a given revision or revision range and creates the set of changed files in a specified directory. It's easy to zip the directory as part of a script.
To my knowledge, there's not a handy tool for this (though a mercurial plugin might be doable). You can export a patch for the fileset, using hg export from:to (where from and to identify revisions.) If you really need the entire files as seen on tip, you could probably hack something together based on the output of hg diff --stat -r from:to , which outputs a list of files with annotations about how many lines were changed, like:
...
src/test/scala/RegressionTest.scala | 25 +++++++++++++----------
src/test/scala/SLDTest.scala | 2 +-
15 files changed, 111 insertions(+), 143 deletions(-)
If none of your files have spaces or special characters in their names, you could use something like:
hg diff -r156:159 --stat | head - --lines=-1 | sed 's!|.*$!!' | xargs zip ../diffed.zip
I'll leave dealing with special characters as an exercise for the reader ;)
Here is a small and ugly bash script that will do the job, at least if you work in an Linux environment. This has absolutely no checks what so ever and will most likely break when you have moved a file but it is a start.
Command:
zipChanges.sh REVISION REPOSITORY DESTINATION
zipChanges.sh 3 /home/hg/repo /home/hg/files.tgz
Code:
#!/bin/sh
REV=$1
SRC_REPO=$2
DST_ZIP=$3
cd $SRC_REPO
FILES=$(hg status --rev $1 $SRC_REPO | cut -c3-)
IFS=$'\n'
FILENAMES=""
for line in ${FILES}
do
FILENAMES=$FILENAMES" \""$SRC_REPO"/"$line"\""
done
CMD="tar czf \"$DST_ZIP\" $FILENAMES"
eval $CMD
I know you already have a few answers to this one but a friend of mine had a similar issue and I created a simple program in VB.Net to do this for him perhaps it could help for you too, the prog and a copy of the source is at the bottom of the article linked below.
http://www.simianenterprises.co.uk/blog/mercurial-export-changed-files-80.html
Although this does not let you pick an end revision at the moment, it would be very easy to add that in using the source, however you would have to update to the target revision manually before extracting the files.
If needed you could even mod it to create the zip instead of a folder of files (which is also nice and easy to manually zip)
hope this helps either you or anyone else who wants this functionality.
i just contributed an extension here https://sites.google.com/site/alessandronegrin/pack-mercurial-extension
I ran into this problem recently. My solution:
hg update null
hg debugsetparents (starting revision)
hg update (ending revision)
This will have the effect of deleting all tracked files that were not changed between those two revisions. You will have to remove any untracked files yourself, though. After doing this, the local branch will be in an inconsistent state; you can fix this by running hg debugrebuildstate (or simply deleting the local branch, if you no longer need it).