I have a mercurial project of my website. I have symlinked (Mac OS X aliases) lot of files from here `to elsewhere. I made a mistake to add and commit all the aliases in my repository too.
However now I want to keep them untracked, so I added an entry in my .hgignore -
syntax:glob
*.pdf
*alias
[... snipped ...]
But I still see them when I do hg status
$ hg status
M documents/.../x alias
M documents/.../y alias
M documents/.../z alias
[... snipped ...]
You need to tell hg to remove or forget these files, because right now they are still in your repository, and hg won't ignore files that it's already tracking--it will just ignore files that aren't already tracked.
Related
A little while ago I noticed that hg started creating unversioned copies of files in the repository at seemingly random times when I update between branches. I can't for the life of me think of what I might have changed for this to start happening. There is nothing in the verbose or trace output to indicate that these files are being created.
The new unversioned filenames all end with what seems to be a random string added to the end of the extension:
file1.txt-23121dd1
someotherfile.sql-bc769bd2
bizarrofile.cs-40a93ed0
hgisinvadingurhead.ppt-f8e9015a
When trying to determine the pattern of this happening I've noticed the following:
The added characters in the filenames do not correspond with any changeset ID in the repository. I have done a grep -i to the output of hg history and the string in the filename does not appear anywhere in the output.
In all cases the files existed in the branch I was working on but do not exist in the branch I update to.
Sometimes it's only one or two files, sometimes it's several.
It is never the case that these are all of the files that exist in one branch but not the other.
It is never the case that it is the same set of unversioned files between updates.
Others on my team who are cloning the same repositories do not seem to be experiencing this
I thought maybe it was something within the repository but it also happens in other existing repositories and in brand new ones as well.
For example, I have done this (hg output omitted except for hg status output at the end, but no errors come from the output):
c:\> mkdir repo
c:\> cd repo
c:\repo\> hg init
c:\repo\> echo default > default.txt
c:\repo\> hg add
c:\repo\> hg commit -m "Commit default"
c:\repo\> hg branch branch1
c:\repo\> echo branch1 > branch1.txt
c:\repo\> hg add
c:\repo\> hg commit -m "Commit branch1"
c:\repo\> hg update default
c:\repo\> hg status
? branch1.txt-23121dd1
This is not repeatable every time. I could repeat these steps and sometimes the unversioned file will be there at the end and sometimes it won't. It's very sporadic. In larger repositories, though, I almost always see at least one unversioned file between branch updates.
Full output of hg update default follows. The output always displays as such whether or not the unversioned file is created.
resolving manifests
calling hook preupdate.eol: <function preupdate at 0x0000000002571668>
removing branch1.txt
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
I was using an older version of hg when I first noticed it but the problem still exists after updating to 2.3.2. I am using Windows 7 Pro x64 with TortoiseHG 2.5.1 x64. I don't think it's related to Tortoise, however, because I can replicate the problem by just using hg from the command line.
The contents of my mercurial.ini file are:
[ui]
username=myname <myname#mydomain.com>
ignore=C:\users\myusername\.hgignore
verbose=true
trace=true
[eol]
native = CRLF
only-consistent = False
[extensions]
purge =
eol =
I can live with it, but it's a pain to make sure I'm not accidentally adding these files to the repository in changesets with other new files.
If someone has seen this and could point me to the culprit I'd be most appreciative!
If a file is in use when updating between changesets, the in-use file is renamed with the added numbers so the update can succeed.
Does disabling the eol extension help matters? I noticed that your test did not use a .hgeol file as well (that's one of the things associated with this extension). There's another thread hereabouts that is dedicated to some problems with this extension.
Sometimes I can't seem to be able to track the merge conflicts.
I need a command that allows me to discard one of my uncommitted files and then update it with the remote copy.
I tried hg revert myfile followed by hg pull , hg commit
but it still won't let me merge or commit.
It keeps telling me to fix unresolved conflict first.
You might need to let Mercurial know that you have resolved the conflict, using hg resolve. From the man page:
hg resolve [OPTION]... [FILE]...
redo merges or set/view the merge status of files
Merges with unresolved conflicts are often the result of non-interactive
merging using the "internal:merge" configuration setting, or a command-
line merge tool like "diff3". The resolve command is used to manage the
files involved in a merge, after "hg merge" has been run, and before "hg
commit" is run (i.e. the working directory must have two parents). See "hg
help merge-tools" for information on configuring merge tools.
The resolve command can be used in the following ways:
- "hg resolve [--tool TOOL] FILE...": attempt to re-merge the specified
files, discarding any previous merge attempts. Re-merging is not
performed for files already marked as resolved. Use "--all/-a" to select
all unresolved files. "--tool" can be used to specify the merge tool
used for the given files. It overrides the HGMERGE environment variable
and your configuration files. Previous file contents are saved with a
".orig" suffix.
- "hg resolve -m [FILE]": mark a file as having been resolved (e.g. after
having manually fixed-up the files). The default is to mark all
unresolved files.
- "hg resolve -u [FILE]...": mark a file as unresolved. The default is to
mark all resolved files.
- "hg resolve -l": list files which had or still have conflicts. In the
printed list, "U" = unresolved and "R" = resolved.
Note that Mercurial will not let you commit files with unresolved merge
conflicts. You must use "hg resolve -m ..." before you can commit after a
conflicting merge.
Here's how you pick up the version of the file from the server.
When you "hg pull", all changes from the server come into your copy of the repository. You can get the contents of a file in any revision using:
hg cat -r <rev> <file>
Use that to overwrite the local file, and commit.
First off, I would prefer not to check in the generated files at all but my manager insists. So, given those constraints I would like to create a mercurial "merge-patterns" that will always take "their files" in all directories named "generated" in my working repo. I have read the hgrc documentation and a related post and here is what I think it should look like:
[merge-patterns]
generated/** = internal:other #keep their files
And this is placed in my root .hg/hgrc file. When I run the hg update with the merge conflicts this is what I get:
> hg update
couldn't find merge tool internal:other #keep their files specified for generated/**
merging generated/file.sv
So I modified the "merge-patterns" to look like this:
[merge-patterns]
**/generated/** = internal:other #keep their files
And here is what I get:
> hg update
merging generated/file.sv
So, I no longer get the "couldn't find merge tool internal:other" warning but it is still trying to merge the generated files.
Any ideas on how to get this to work?
Additional notes:
We are using Mercurial version 1.7.5 as we were having problems with newer versions and subrepos.
I am working with subrepos so here is what the structure of my main repo looks like:
I believe the problem is simply the comment! Mercurial is searching for a tool named
internal:other #keep their files
and that's unlikely to exist :-) Try moving the comment to a line above:
[merge-patterns]
# keep their files
generated/** = internal:other
I haven't tested this out, but I believe you still need the first pattern you used — the warning went away with your second try because the pattern no longer matched inside the subrepo. Even when you start the merge from the top-level, the subrepos are merged as if hg merge was executed inside the subrepo.
according to Mercurial's commit help message:
If a list of files is omitted, all changes reported by "hg status" will be
committed.
Is there an easy way to change this behavior?
I'd like Mercurial not to commit any changes, unless the files are explicitly specified.
edit
I am on Linux and I am using the command line.
This seems to do the trick:
$ hg commit -X *
nothing changed
It doesn't do anything because all files are excluded, but if you give any files, those will be included.
You could alias it:
[alias]
xcommit = commit -X *
then:
$ hg status
M a
M b
$ hg xcommit -m 'no files specified'
nothing changed
$ hg xcommit -m 'picking a' a
$ hg status
M b
Personally I wouldn't want to get used to this type of workflow. It's usually just as easy to:
work in smaller chunks so your changes reflect a single changeset
for the times when you forget and you're on a coding spree, use something like hg record
for the really few times when the above two don't fit, use -I/-X for that single commit
if you are using GUI like tortoiseHg you can select the files you need to commit. http://tortoisehg.bitbucket.io/
We have a Mercurial repository converted from Subversion a while ago and have today noticed that there are files in the repository that have no history whatsoever.
One of the sympomts of this behaviour is that hg status reports the file as clean, while hg log reports no changesets for the same file:
> hg clone [repo]
> hg st -c FileWithMissingHistory.cs
C FileWithMissingHistory.cs
> hg blame FileWithMissingHistory.cs
FileWithMissingHistory.cs: no such file in rev [...]
> hg log FileWithMissingHistory.cs
> hg log FileWithMissingHistory.cs -f
abort: cannot follow nonexistent file: "FileWithMissingHistory.cs"
> hg log -v | grep FileWithMissingHistory.cs
[gives output, there arechangesets mentioning the file]
Obviously the filenames have been changed in the example. I've tried using hg verify, but this command reports that the repo is fine. Has anyone experienced this and is there anything we could do to bring the history "back to life"? Placing dummy history on the files in question would be acceptable, but suboptimal.
EDIT:
I've done some more investigation and noticed that "FileWithMissingHistory.cs" was renamed from another filename (hg copy + delete) in revision 238. If I do hg update -r238 and hg log on the file at this revision I do not get any history. Doing hg log on the original file reports the history as expected, so it seems that the history is somehow lost during copy (again, the file is renamed using hg copy, and the changeset clearly indicates that the file has been copied).
Sounds strange, actually impossible. What I would try to debug this issue is to update to different revisions and check at which revision the file appears in the working copy the first time. If you do this in a binary search fashion (similar to how the bisect extension works), you should find a revision which introduces the file after a few updates.
This does not solve the problem, but it may help in tracking down its source.
I've finally tracked down the cause of the effects mentioned above and it seems that this is caused by mixed casing issues. Some of the files are located in directories with lowercase names while others are located in the directories with equal names, only that the case is mixed (e.g. "directory/FileWithHistory.cs" and "DiReCtOrY/FileWithMissingHistory.cs"). On Windows, both files will be located in the same directory causing issues.