I use this .hgignore file liberally in my projects, it has proven worthy so far.
However, every once in a while I'd like to do a reality check, to make sure it didn't eat up something valuable.
My question is: how can I find out the exact list of excluded files? (The files that actually match the .hgignore patterns)
Answers using TortoiseHg or command-line are welcome.
The command hg status --ignored (or hg status -i) lists the files that have been ignored.
The answer hit me while I was finishing the question (yet again).
It's trivial, actually:
Start by making sure there are no pending commits.
(Re)move/rename the .hgignore file
Hit 'Refresh' in TortoiseHg's commit window.
You'll now get the exact list of ignored files (+ the change to the .hgignore file itself).
Rubber ducking at its best. (Hmm, SO should add a badge for this :)
Related
I have a branch on Perforce, where I changes the directory structure of the project using Rename/Move command.
During merging back to the mainstream, Something went wrong that caused Perforce to think of the new structure as a whole-new directories.
Subsequently, the history of the files in the new directory structure is totally unrelated to the history of the same files before changing the structure.
Is there anyway to recover this situation ? Or ask Perforce to append the old history with the new history ?
Something went wrong that caused Perforce to think of the new structure as a whole-new directories.
Usually if this happens it means someone didn't use the "rename/move" command and used some other method to rename instead (i.e. they did something that adds the new directory as a new set of files independent of the originals rather than an atomic rename of an existing set of files). It's impossible for me to say how to "recover" without seeing what the history of the files looks like now so I can reverse-engineer what the "something went wrong" was.
I'd recommend either posting on the Perforce forums or contacting Perforce technical support so that somebody with expertise can wheedle the necessary data out of you (I can intuit that this will require an amount of back and forth that stackoverflow frowns on -- "what were the branches you were merging from and to", "okay, now run THIS command to see the history of that branch and send me the output," "okay, which of these five merge operations I can see in the history is the one you're talking about,") and propose a solution.
From another answer:
So, for a file a/b/c, you can look at the by using the -i option where appropriate. For example, p4 filelog -li a/b/c.
This is not necessary if files are renamed via the "move/rename" command, so if you need to use "filelog -i" to see file history, the files were definitely renamed by some other method. (The "p4 move" command was added in 2009 so long-time Perforce users will sometimes use other workflows.)
I'm in the process of doing a merge, and I'm ready to commit at this point but my commit dialog in TortoiseHg is showing many files as modified but when I diff to parents it says all files are binary equal.
I do not have and have never had the eol extension enabled.
Revert changes nothing, the file is still registering as modified.
hg parents shows two parents for the file.
hg stat shows the file as modified, e.g.
c:\Projects\MyProject>hg stat Authorization\AuthorityGroups.cs
M Authorization\AuthorityGroups.cs
hg diff --git shows nothing, e.g.
c:\Projects\MyProject>hg diff --git Authorization\AuthorityGroups.cs
c:\Projects\MyProject>
I've tried this on two different machines on two separate clones and I'm seeing the same thing.
Any other thoughts for how I could diagnose or fix this?
Clearly something has changed but if it's not showing in hg diff --git how can I establish what that might be?
Update 2014/12/10:
I've done a bit more checking on the history of the two parent revisions and I think I see why it's getting confused.
We've got the original parent file added in revision 1 on default.
On the Apple branch the file has been renamed to move it to a new location.
On the Orange branch the file has been added to move it to the same new location.
So the file on both branches is binary identical and at the same location, but presumably Mercurial is flagging it as a difference to be merged because they arrived there by apparently different means.
So the question then becomes:
Is there any way to retrospectively repair the move being treated as an add and delete on a long committed changeset (a new commit would be fine, but I can't edit the history) , or do I just need to let it go through in the merge?
Is there any way to retrospectively repair the move being treated as an add and delete on a long committed changeset (a new commit would be fine, but I can't edit the history)
Well... sort of. Update to the most recent Orange commit in which the files had their old names (you can use hg bisect to find it if you're not sure exactly when it happened), do hg rename to the new names, commit, and then merge this into the current Orange head. Mercurial should be smart enough to register the files as properly renamed, and it won't cause conflicts (we know this because the more complex Apple/Orange merge didn't).
or do I just need to let it go through in the merge?
This is easier. Mercurial's merging algorithm is quite smart. It can deal with situations like this just fine.
Unless you have a third branch in which the files were never moved, the second option is unlikely to cause a problem. If you do have such a branch, you should be fine as long as you merge it into a descendant of the Apple rename (or merge from such a descendant). The major difficulty would be with merges to or from the Orange branch.
Can you diff with the reverted copy?
I was doing work in the wrong repo. They are almost the same, but have no actual relation.
I just did a pull and an update, can i then copy my changed files into the Right head and then run a diff on it or something similar and then properly merge the 2 together?
I feel an alternate option would be do something like
copy the code over and commit it, then revert back, and merge with the commit to diff what has all changed..
I have changing something like 1500 lines over 9 files, so i dont want to rewrite a bunch of code segments.
How should i handle this?
It really depends on how similar the "almost the same, but have no actual relation" repositories are.
If they extremely similar (as in files have the same names and text is almost identical), you might get by with exporting a patch at the source repo and then importing the same patch into the target repo.
In the source repo:
hg export -r tip > path\to\oops.patch
and in the target repo:
hg import path\to\oops.patch --no-commit
I used --no-commit since I assume you will need to do some cleanup first to make sure that everything looks ok.
Alternatively, you could just compare the two directories using kdiff or BeyondCompare3 and bring over the differences that you want from the source repo to the target repo and commit it that way. This would probably be my approach.
(I am intentionally ignoring the question about why you have two repositories that are that similar but don't have a shared history. For all I know, it might be the right thing to do.)
When it comes to Mercurial;
What exactly is the difference between the following:
Stop Tracking
Ignore
Google Search, SE search brings no clear examples / results on the matter.
Generally speaking, as it isn't clear in what context you came across those terms:
Ignore adds a file name pattern to the .hgignore file. It means any files matching the pattern will not be version controlled unless they have already been added (by hg add or hg addrem). So any files that are already part of the repository will not be affected by .hgignore.
Stop Tracking (hg remove or hg forget) means that Mercurial will not record any changes made to the file and the file will no longer be part of the repository. If the file is still present in the file system, it will show up as ? (not tracked). This action takes effect with the next commit, not immediately.
I have used mercurial for some time now and never had any problems using hgignore.
Now I have created a new project using eclipse, which added a .metadata directory.
I seem to be unable to ignore the .metadata.
nils#yavin $ hg status
? .metadata/.mylyn/repositories.xml.zip
? .metadata/.plugins/org.eclipse.core.resources/.history/37/509db4063df7001f14dbbfe704ff2c4e
...
My .hgignore looks like this:
syntax: regexp
/\.metadata/.*
\.metadata/.*
glob:.metadata/*
glob:.metadata/.mylyn/repositories.xml.zip
As you can see, I tried some things... I even tried adding one file directly, but it did not work.
Is there any magic involved when dealing with dot-directories? Or am I simply stupid today?
Just remove everything and leave:
glob:.metadata/*
The first line syntax:regexp in your .hgignore is making hg treat all subsequent lines as regex, including the one with glob:.metadata/*