I made one little change (removed some trailing whitespaces) then
I ran hg diff [File Name], and it says all lines are modified.
I had this problem before then it was fixed somehow then it's back again.
I didn't upgrade mercurial or anything.
Did anyone experience something like this and managed to figure out a way to fix it?
Thanks.
Related
I seem to have made a mistake when performing a series of rebase, strip, and shelve operations. The result is that I am unable to unshelve. When I run hg unshelve in the current state, it just throws an ugly error:
# hg unshelve
unshelving change 'repo-02'
abort: 00changelog.i#5bd4b71e0176: unknown parent!
I think what has happened is that after shelving a change (or maybe a series of shelves) I stripped / rebased away a commit which was a dependency of the shelf.
The shelf has changes to a number of "random" files - meaning their changes are unrelated (mainly temporary debug output, things like that). So even with the single stripped file gone, the remaining parts of the shelve should be OK to use - but how can I get past this error?
One method of getting around this might be to undo the stripped changesets. But before I did that I found another method which worked, and I think this was ultimately simpler as I had a large # of strip backups to work through.
Looking in the .hg\shelved\ folder I actually had data files from several shelve 'events'. They looked something like this:
repo-01.hg
repo-01.patch
repo-01.shelve
repo-02.hg
repo-02.patch
repo-02.shelve
repo.hg
repo.patch
repo.shelve
Reading these file contents I noticed that the .patch files were indeed standard diff-style patches.
Also by looking at the contents of all 3 shelves I could determine that it was only the "repo.patch" (the oldest one) that I actually needed.
(Initially I tried removing the 01 and 02 files and unshelving, but this produced a different error, so I reversed course.)
I then ran:
hg patch --no-commit repo.patch
from within that folder. This basically worked fine, and now my working folder contained modified files again, and they checked out as having the expected contents.
Interestingly because of the original mistake (stripping a commit) one of the files in that patch failed to apply - because the file no longer exists. But fortunately hg patch was resilient enough to just skip over this. Since the file was deleted intentionally, this was not a problem.
Following the above, I used:
hg shelve --cleanup
to get rid of the messy state. Shelve / unshelve now work normally again.
First things first, I'm a total moron for even being in this position at all. Newish dev with < 2 years experience and not a lot of time with version control, much less hg and tortoisehg.
I wanted to revert a merge, so after several failed attempts to create a new branch from my last good commit and merge it back into my local branch, I discovered the rebase extension could strip back to a good commit. (That said, since I had already pushed my bad commit, it didn't really solve my problems).
I went ahead used rebase > strip a few times nevertheless, and now tortoisehg hangs whenever I try to update.
hg cli still works, it's just tortoisehg that I seem to have broken. Tried uninstall/reinstall of tortoise, no luck.
I find that other guys in the office can pull and update without problems, so it's strictly a local problem.
Any suggestions on how to restore functionality? Thanks in advance.
I ran another uninstall using ccleaner, and then did a search for anything related to tortoise in my C:/ drive. Renamed every entry I could find (mostly in AppData/Roaming) and then reinstalled thg. Successfully updates and does everything else as usual now.
I'm tearing my hair out here...
I've told TortoiseHg to create a repo of a directory that contains a mix of text files (mostly XML) and binary files.
I've done an initial commit, adding all files and ignoring .hgignore. Done.
Then I edited one of the XML files and saved.
The file indeed changed; I can see that the Initial Commit version has not the added line, while the version on the disk has the added line.
But for unknown reasons, Hg Workbench won't show the changed file!
I've tried pressing the 'refresh' buttons, all to no avail.
What is going on here? Is there a setting I've overlooked that caused TortoiseHg to ignore all files?
FYI, the .hgignore file only contains the following:
syntax: glob
.hgignore
I'm using TortoiseHg v3.0.1.
Total folder size is 280,240,487 bytes (lots of binary resources).
Thanks for any help!
EDIT: I still don't know what had gone wrong... but I accidentally fixed it:
I opened the XML file again, and serendipitously saw that I actually made a typo.
I fixed the typo, and re-saved the file.
All of a sudden, Hg Workshop saw the change!
Commit before Hg Workshop changed its mind.
Thanks for trying to help me... at the moment, I'm content that the 'invisible change' is fixed.
(Although I'm still wondering what had caused it in the first place.)
Someone accidentally mashed their l key while merging .hgtags a couple weeks ago, and we started getting messages about how .hgtags#eed03ad8bbe7, line 1: node 'll005a7e9815cb34a143f349469b6b3c27174af7f6' is not well formed.
I went and fixed the tags file, and everything seemed hunky dory, but now when people clone they get that message. Is there a way to turn it off? Do I have to edit history and tell everyone in the company to blow away all their repositories and re-clone?
I think (but aren't certain) that Mercurial looks at the .hgtags file in all heads when parsing. Check hg heads to see all heads and add a commit to each one that still has the malformed file and new cloners should be okay. People who have their own branches that still have the malformed data in the tip will get that message until they merge the fix into their branches (be they named or anonymous/bookmark)
Disclaimer: there's a 50% chance I'm wrong about that. :)
We are just beginning to learn and evaluate Mercurial, due to an increasing number of nightmare merges, and various other problems we've had with SVN lately.
A client wants us to pull down a live copy of their site, do some SEO work on it, and push it back to them. They have no source control at all. I figure this is a great project to work on with Mercurial. Instead of putting it into our SVN and exporting when we are done, we'll use Mercurial... But right away it seems I have some problem :)
They have a file called ---.config which seems to cause our Mercurial to barf. It just can't commit that file. I've created the repo and committed everything else, but I just can't get this one file committed.
We are running on Windows 2008 x64 with TortoiseHG 1.0.
I suppose I could ignore the file since it is unlikely we'll need to work with it, but still - I'd like to learn how to use Mercurial a bit better. Is there a way around this?
EDIT: here is the error message:
('commit', GetoptError('option ---.config not recognized', '-.config'))
This happens when I hit the "commit" button in TortoiseHG with that file selected.
Not sure about hg, but most command line tools treat anything after a -- as a non-option. This is helpful if you have a filename that starts with -- or a wildcard that picks up such a file; try prefixing your filename or wildcard with --, e.g., hg command -- *.config.
The problem is that TortoiseHg did not escape filenames correctly when calling hg. When a filename starts with --, one must take extra care when using it on command lines.
I have just sent a patch which will hopefully make it into TortoiseHg 1.0.1, which is scheduled to be released later today.