I'm definitely missing something about how to use hg blame.
I have a particular line in a file Foo.csproj that is suspicious and I want to see who modified it. According to other answers this should be a matter of hg blame Foo.csproj, maybe hg blame -unl Foo.csproj.
Either one of these returns to me
abort: Foo.csproj: no such file in rev xxxxx
I've tried with fully qualified paths and not. What's going on? Am I using the feature wrong? What is it meant for? How do I find out what I want to find out (the last person to modify line 1700 of that file).
Note, that while I'm interested in how this is done in Sourcetree, and TortoiseHg, and I'm sure others might be interested as well, I specifically want to know how to do this with the command line client.
Blame works exactly like you'd expect and your sample commands are correct, so I suspect you're running into something tricky. Here's an example of the normal case:
ry4an#four:~$ hg init GeorgeMauer
ry4an#four:~$ cd GeorgeMauer/
ry4an#four:~/GeorgeMauer$ echo test > afile.txt
ry4an#four:~/GeorgeMauer$ hg commit -Am first --user George
adding afile.txt
ry4an#four:~/GeorgeMauer$ echo more test >> afile.txt
ry4an#four:~/GeorgeMauer$ hg commit -m second --user Other
ry4an#four:~/GeorgeMauer$ hg blame afile.txt
0: test
1: more test
ry4an#four:~/GeorgeMauer$ hg blame -u afile.txt
George: test
Other: more test
ry4an#four:~/GeorgeMauer$
Is it possible that you're running afoul of the hideous "case-insensitive, but case-retentive" properties of Windows (and Mac) default file systems?
Try hg manifest to make sure the case of the filename you're providing is what's recorded in the repo, which may be different from the file you have on disk. For the example above mine looks like:
ry4an#four:~/GeorgeMauer$ hg manifest
afile.txt
If yours includes, for example, foo.csproj then that's how you have to ask about it.
The error message you're getting is the one you see when you ask about a file that's not in your repository:
ry4an#four:~/GeorgeMauer$ hg blame filedoesnotexist
abort: filedoesnotexist: no such file in rev 72a94e6fe429
So either it was never added and committed or, more likely, you're calling it by its wrong name.
Related
Question title is pretty much the question. Here's a look at what I get:
I am trying to export a mercurial repository to git, but to a different directory. hg gexport works just fine without the --cwd parameter, but I don't want that -- I want to change the working directory to another one, but strangely, it says unknown command when I use that command line switch.
Any ideas?
Real hgexport is not native hg command, it's part of hggit extension
According to wiki, this part ("Using hg-git to interact with a hg repository with git") is outdated and may not reflect current state of extension
>hg gexport --cwd $PATH work in my own tests without errors (so-so, see below) with command-line expanded accordingly to requirements
hg gexport --cwd i:\Work\Personal!whyhq\ -R i:\Work\Personal!whyhq\site
without -R gexport will not find source hg-repo after cdto target location
And last, but not least: even properly used, hgexport in current hggit
hg id
15457fc67631 0.8.13
do nothing (nothing changed on target). I suppose, for getting git-repo from hg you have to use trivial hg push <git-URL> today (yes, it work, with minimal tricks on your side: branch_bookmark_suffix = $STRING in .hgrc)
Side note
If you have hggit extension enabled (globally or per-repository) hg-repo is mirrored automagically into bare git-repo (at least it seems so) in .hg/git directory, you can just copy&rename it
Is there a problem with Mercurial's guide for fixing case-folding collisions or is there a problem with the way I am implementing the solution.
The solution as provided on the Mercurial wiki is as follows:
hg clone -U repo repair
cd repair
hg debugsetparents <bad revision>
hg debugrebuildstate
At this point, Mercurial will think you have the bad revision checked
out and all the files are missing (status '!'). To fix the repo, we
simply have to do:
hg rm -A <file causing the collision>
Now hg st should show the troublesome file in state 'R' and all other
files in state '!'. Now we can check in our fix:
hg ci -m"fix case collision"
To get all our files back, we just check out again:
hg co tip
The problem files are: SomeFile.bash and Somefile.bash. I originally had Somefile.bash and I would like it to now be SomeFile.bash. Also to note, version 157 is happy, no collision, but version 158 is where I have introduced the collision. The head of the repository is currently at revision 160.
I have implemented this solution as follows:
hg clone -U my-repo-url repair
cd repair
hg debugsetparent 160
hg debugrebuildstate
hg status (reveals that everything is 'missing' (!))
hg rm -A Somefile.bash (responds that SomeFile.bash has been removed, notice case change)
hg ci -m "Fixed the collision... I hope."
hg co tip
hg update -C tip
According to the guide, this should have removed the case-folding collision and brought the rest of the missing files back, yet another hg status reveals that everything is still missing (!).
Edit: By appending that last command (the update) to the existing commands, I was able to recover the missing files which solved the remainder of the problem.
Note: I had to use the most recent 'problem' version for <bad revision> to fix this problem (that was 160 in my case).
Try
hg update -C tip
That should bring the files back. If not, try reverting everything:
hg revert -r tip -a
I am looking for the mercurial equivalent of the solution to this question:
How do I "git blame" a deleted line?
In short, I am looking at a mercurial commit where a line was added, and in the current revision this line is no longer present, and I want to find when and why it was removed.
hg grep will let you search a change log for a pattern, such as a deleted string. If you are looking for more than just the first occurrence, be sure to include the --all flag. For me it looked something like this:
hg grep --all -r 9876:tip "pattern" path/to/file
Thanks to Anton for the helpful comments and krtek for his related answer.
hg log -p fileName > fileName.log
Then open the fileName.log file
In there you will find commit the details of each commit along with the diff of that commit. The details of the commit includes the username.
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/
I'd like to use TortoiseMerge with Mercurial to resolve conflicts, but its reporting every line in theirs and mine as added as though its not comparing properly
here is my mercurial.ini:
[ui]
merge = TortoiseMerge
[merge-tools]
TortoiseMerge.executable=C:\Program Files\TortoiseSVN\bin\TortoiseMerge.exe
TortoiseMerge.args=/mine:$local /theirs:$other /base:$base -o /merged:$output
I'm using Hg 1.7.5
What's going on?
Update: When using KDiff or BeyondCompare, the base is always empty.
Thanks
Your setup appears correct.
This is symptomatic of having no copy of the file in the base revision, in which case Mercurial acts as if the file was present but empty.
There are a couple ways of figuring out what's going on here. If there are no copies or renames involved, you should be able to simply do:
$ hg log -r "ancestor(p1(), p2())"
..to determine the ancestor of the merge, then:
$ hg manifest -r <rev> | grep <your file>
..to determine if the file was in fact present.
Alternately, you can run 'hg merge --debug' or 'hg update --debug' to see what changeset and file it's choosing for the merge (including rename/copy details).
If you find that the file is present in the common ancestor Mercurial chooses, then you should report a bug (including your debug output) at:
https://www.mercurial-scm.org/wiki/BugTracker