How do I get mercurial to show the diff during `hg com`? - mercurial

Is there a way to configure hg com so that in the commit message file that pops up in the external editor, instead of just showing which files were changed (in the HG: lines) it actually shows the full diff? I'd rather view the output and compose my commit message simultaneously from the comfort of my text editor as opposed to doing hg diff on the command line separately beforehand.

As of 2016, it's possible to do this with the committemplate configuration option. Adding the following to an hgrc file will include the diff in the editor window inline as you type your commit message.
[committemplate]
changeset = {desc}\n\n
HG: {extramsg}
HG: user: {author}\n{ifeq(p2rev, "-1", "",
"HG: branch merge\n")
}HG: branch '{branch}'\n{if(currentbookmark,
"HG: bookmark '{currentbookmark}'\n") }{subrepos %
"HG: subrepo {subrepo}\n" }
{splitlines(diff()) % 'HG: {line}\n'}
See hg help hgrc and search for committemplate for more information.

Mercurial doesn't have that as a built-in feature, but it's easy to simulate in your editor (as launched by commit).
Here's an example using VIM: https://www.mercurial-scm.org/wiki/DiffsInCommitMessageInVIM
The hgeditor script https://www.mercurial-scm.org/hg/hg-stable/raw-file/tip/hgeditor provides further examples.
The basic jist is:
at editor launch run hg diff redirecting to a temp file
have your editor load both the commit message file and the diff

TortoiseHg does this out of the box: a top panel for the commit message and below that, a left pane listing the affected files and a right pane showing the diffs, one after the other.

Related

What does thg drag_move do? How is it different from hg add and hg remove?

As a user of TortoiseHG, I have been wondering how the thg drag_move command works which mimics (or implements) the functionality behind the "HG Move versioned item(s) here..." context menu entry.
The help entry obtained via thg -v help drag_move gives:
thg drag_move SOURCE... DEST
move the selected files to the desired directory
As far as I understand, it must execute the following sequence (or similar) under the hood:
hg forget SOURCE
mv SOURCE DEST
hg add DEST
But if I do that manually (outside of TortoiseHG), it (naturally) doesn't associate DEST with SOURCE, it rather treats them as individual, unrelated changes.
If I use the GUI or the thg drag_move command, it keeps the history of these entries the same, at least within TortoiseHG I can still see SOURCE's history when I look at DEST's history after the move.
Is this a TortoiseHG extension to Mercurial or is there a hg option to achieve the same "natively"?
TLDR: You can use hg move OLD NEW to achieve the same functionality as thg drag_move.
Thg is using hg move under the hood when it's doing drag_move (see the run.py and quickop.py sources for details).
Hg move is the right way of renaming or moving a file in Mercurial because it's tracking the operation, as it says in his help message (hg help mv):
rename files; equivalent of copy + remove
Mark dest as copies of sources; mark sources for deletion. If dest is a
directory, copies are put in that directory. If dest is a file, there can
only be one source.

tortoisehg one step commit push - how to and where is the log file

Iam using win xp with Tortoisehg 2.3. I use bit bucket to backup my personal source code. (rarely for true version control, more as a source backup store). Right now I have to right click on my repo, select commit, then enter a commit message ( i choose to just copy the same message I used last time, there is a drop down to do this), then click commit. Then I again right click and select synchronize and go thru this option to finally push. I could use the workbench and do something similar. I want to optimize this process so I decided to just write a dos bat script to commit and push. When I push Tortoisehg spits out the hg command to the window and you can see it and cut and paste from here. For the commit it does not show what it is really doing under the hood. When I used TortoiseSVN long back I recall there was a logfile where all svn commands executed were stored for debugging. So I started searching for a TortoiseHg logfile.
Does anybody know:
1) Does Tortoisehg have a logfile somewhere where it stores all mercurial commands executed complete with all the command line options ?
2) Is there a better way to do a one step commit push (via Tortoisehg gui or bat or some addon/extension etc)?
regards
There's actually an option in TortoiseHg to do this:
From your Commit window click on the "Options" button next to the "Copy message" button you've been using.
This pops up a window with a few options - the third one down is "Push After Commit". Tick that.
Enter "default" into the box next to the option
Click "Save in Repo" so that it is saved for next time
Now it will push to the default push target every time you commit from TortoiseHg. One thing to note is that this won't result in an automatic push if you commit from the command line whereas Martin's solution will.
1) Does Tortoisehg have a logfile somewhere where it stores all mercurial commands executed complete with all the command line options ?
TortoiseHg is actually not very related to TortoiseSVN — the two projects share almost no code and are developed by different groups. So I don't think that there is a log file for TortoiseHg even though TortoiseSVN has one.
2) Is there a better way to do a one step commit push (via Tortoisehg gui or bat or some addon/extension etc)?
You could setup a post-commit hook. Add this to the .hg\hgrc file for your repository (create the file as needed):
[hooks]
post-commit = hg push
That way you will run hg push after every commit, even when the commit is done from TortoiseHg.

How does Mercurial tell a file was modified?

How does Mercurial tell a file was modified?
The reason I am asking is because when I run hg status its telling me several files are modified.
However, when I run hg diff there are no changes to report.
I have a theory as why this is happening: (but I am not positive)
I am using NetBeans which has Mercurial support built in. When I edit a file, it shows it as modified, although if I undo (rather than revert) those changes and save it, NetBeans tells me there are no local changes. So I am guessing NetBeans uses diffs to check for modifications while Mercurial is using something else like modification-date.
Is this correct or is something else the cause?
Mercurial does not use modification date to determine the status. This can be verified with a simple experiment:
hg init
echo "This is a test" > test.txt
hg commit -Am "commit"
touch test.txt
hg status
The code which performs the status check is in dirstate.py. If the dirstate is unsure about a file's status (e.g. because only the modification time differs, then it passes it up to localrepo.status for further analysis as seen here.
The hg help status text has some clues that may help:
status may appear to disagree with
diff if permissions have changed or a
merge has occurred. The standard diff
format does not report permission
changes and diff only reports changes
relative to one merge parent.
When you run hg diff, are you specifying any command-line options?
Is it possible the permissions of the file changed? Try hg diff --git which shows the git-style extended diffs that support permissions and binaries. By default hg diff shows only patch-friendly diffs, which don't show permissions changes.

How to view revision history for Mercurial file?

For a given file in a Mercurial repository, how can you see the revision history?
And how can you diff two revisions of the file?
Ideally doing all this with visual tools (we use ExamDiff to do some other diffs).
I'd say this is basic source control functionality but I can't seem to figure out how to do this with Mercurial.
hg log file
hg diff -r 10 -r 20 file
The hgk extension gives you hg view file command that shows a visual history, from which you can diff/vdiff arbitrary pair of revisions.
TortoiseHg gives you thg log file command that does the same thing but looks better.
For readability
hg diff -r revision1:revision2 file
Where revision1 and revision2 can be a tag, changeset etc.
If you use TortoiseHg:
Windows users can use Windows Explorer and view the revision history by right-clicking on the file.
For Linux users, you can do it within TortoiseHg but it took me a while to figure out how. You need to right-click on the desired file and select "File History". However, for some mysterious reason, the file needs to be unaltered. Furthermore, to find the desired file there are two options:
In ### revision set query### one can type:
file("**<myfile>")
The double ** are necessary to search directories recursively. This gives you immediately an list of all repositories in which the desired file was changed.
Alternatively, next to the ### filter text ### click first on the question mark sign and select "clean" to see all files in the repository. Then inside the ### filter text ### box you can narrow down the number of files shown.
Alternatively, Linux users can do it from a terminal as suggested by Geoffrey Zheng above:
thg log file

How to commit only a part of the changes made to a file?

I want to commit separately different parts of the same file.
I want to commit line 2 first with the message (changeset 1) and the 4th line with the message (changeset 2). How do I do it?
I am using Mercurial Distributed SCM (version 3.5.2+20151001)
You can do this with the interactive option to commit.
First add the following to your ~/.hgrc file:
[ui]
interface = curses
Then use:
hg commit -i
This will tell commit to allow you to interactively select what files or (by drilling into the file) select sub file changes.
You can use this multiple times, selecting individual changes in the files.
Note: without the addition to your .hgrc, hg commit -i will ask you for each file and not allow you to drill into and select individual file changes.
The interactive option is also being implemented in other mercurial commands such as restore (you can select what changes are to be restored) and the new experimental amend command. It is very powerful and easy to use.