I know how to view all changes in a changeset..
But let's say you update your source, you do a pull and you get 3 new changesets. How can you compare the current state of the remote repository (with the 3 changesets checked in) vs. the current source (on your local machine)?
I'd like to do this using the visual diff tool which I currently have configured (Examdiff or Kdiff3).
You want to compare the current working directory with the tip revision, so you should be able to use hg diff -r tip.
Related
TLDR: I seem to have created a separate repository in a subfolder of my main project. How can I combine them?
I have a project folder, let's call it BOB. I cloned (hg clone) BOB to a new folder called BOB2. To add new features, I created a subfolder on BOB2 called BOB-newfeatures. I have been working on this BOB-newfeatures folder for a while, with many checkins.
Today I realized that somehow I created a separate repository for BOB-newfeatures (I hadn't changed anything on BOB2 main until today so I hadn't noticed that changes weren't being tracked). If I do hg status on BOB2, it doesn't know about changes in the subfolder and vice versa.
Is there a way to stitch these together? I know I could hg add all of the files in BOB-newfeatures to BOB but then I think I lose all of my checkin history.
OK, I reconstructed (I hope) your case, with your names, starting from
BOB2>hg log -T "{node|short}\tFiles: {join(files, ', ')}\n"
25a16a8fea5e Files: Sub/3.txt
bf3c6cacb4a4 Files: 1.txt, 2.txt
ff71a2b1bbe3 Files: 1.txt
and nested repo
BOB2\BOB-newfeatures>hg log -T "{node|short}\tFiles: {join(files, ', ')}\n"
acac7d413ed2 Files: f1.txt
15a1f9cacf25 Files: f2.txt
f3055921fa01 Files: f1.txt
As a additional confirmation of invisibility of BOB-newfeatures inside BOB2
BOB2>hg manifest
1.txt
2.txt
Sub/3.txt
Method of solving problem - using Convert extension with --filemap in inversed, compared to Wiki, direction: it's example transform subdir of repo into separate repository, I'll move repository-root into subfolder
map-file, prepared for conversion
rename . BOB-newfeatures
conversion
hg convert --filemap map z:\BOB2\BOB-newfeatures z:\BOB-newfeatures-conv
initializing destination z:\BOB-newfeatures-conv repository
scanning source...
sorting...
converting...
2 New feature started
1 Change 1
0 Change 2
Testing results
BOB-newfeatures-conv>hg log -T "{node|short}\tFiles: {join(files, ', ')}\n"
a3b2c462a3b9 Files: BOB-newfeatures/f1.txt
f5f1168cfe2f Files: BOB-newfeatures/f2.txt
da27a50a5cb6 Files: BOB-newfeatures/f1.txt
compare file-paths with log from nested repo, note different hashes for changesets
Next bad news: you can't just pull from BOB|BOB2 into converted repository missing parts easy
BOB-newfeatures-conv>hg pull ../BOB2
pulling from ../BOB2
searching for changes
abort: repository is unrelated
Even with --force (because repositories are really unrelated and doesn't share history) you'll get "dirty" combined repository (changes in root and in BOB-newfeatures/ are two separate lines of changes with own roots and tips)
BOB-newfeatures-conv>hg pull ../BOB2 -f
pulling from ../BOB2
searching for changes
warning: repository is unrelated
requesting all changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 4 changes to 3 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
And at last step you have to re-link two histories into one common. In my case due to my actions (pulling to converted repository with pre-existing history of BOB-newfeatures) I had to link 0-1-2 revisions after 3-4-5 (historically earlier changes) and I don't know more elegant way to do it, than again convert (HG->HG) repository, with --splicemap this time
With log output
>hg log -T "{rev} {node}\n"
5 25a16a8fea5e5b4dac42a0a6b2c8e82890c220a3
4 bf3c6cacb4a4c22cb5720ddeab1ec5f8238a98c9
3 ff71a2b1bbe30a56c9dabc9a7ddb2bbccad840af
2 a3b2c462a3b917b3ba58daee3df2632875baee17
1 f5f1168cfe2f4b6c67d0af8a9259665ae2d40bd5
0 da27a50a5cb6246c03c6af7485ac7ffc33e62738
splicemap for rule "0 after 5" can be created (with format of oneliner "ChildHash ParentHash")
da27a50a5cb6246c03c6af7485ac7ffc33e62738 25a16a8fea5e5b4dac42a0a6b2c8e82890c220a3
and last conversion performed
>hg convert --splicemap z:\map z:\BOB-newfeatures-conv z:\BOB3
scanning source...
sorting...
converting...
5 Initial data
4 Changes
3 More changes
2 New feature started
spliced in 25a16a8fea5e5b4dac42a0a6b2c8e82890c220a3 as parents of da27a50a5cb6246c03c6af7485ac7ffc33e62738
1 Change 1
0 Change 2
with expected good results
You simply created a separate repository. As such you can pull from that repository like from any other. In this case, in your main repository in BOB2, you could do:
hg pull ./BOB-newfeatures
In order to avoid confusion, I'd first move BOB-newfeatures to the same directory level as BOB2 and pull then giving the new relative path ../BOB-newfeatures; but that's more for cosmetics and to keep your BOB2 repository clean; strictly speaking it should not be needed.
(Basically you used a feature of hg: you can create a new repo in any sub-path which will be an independent repo which knows nothing of the parent and vice versa. It's used for instance for libraries needed by the main repo but which you do not want to tie directly to your main; they then are found in the expected relative path and it's easy to operate on)
Simple question: is there a way to revert --all from TortoiseHg workbench? I see how to revert an individual file. Ideally, I could click on a revision, and from the right mouse menu find a "revert all" item.
I'm using TortoiseHg 2.8 on a Ubuntu box.
EDIT I should have provided more details on my question to provide some context. Let me describe the particular use case:
I want to put my working directory back to the state of a past commit so I can generate output from the executable that I know was "good". Once I've generated that output, I want to go back to the tip and continue my development, keeping this history linear. From the command line, I did "hg revert --all --rev 22", generated the output, then "hg revert --all", which did what I wanted. "hg update" will create a history with a branch (if I'm understanding correctly). FWIW there is an "update" button in TortoiseHg (in the box where the list of files is shown) as well as a right-mouse menu item on a given revision.
To set the working directory to match the state of a given changeset (which could be tip), you can use Update:
Right click on the changeset you want to 'revert' to.
Select "Update"
Check the "Discard local changes" checkbox
Click Update
It would be hg update -r changeset -C in the console.
Now you can create the output from the 'state' of the working directory at that point in history (i.e. from the executable at that changeset). If you don't make any commits here there will be no changeset created and therefore nothing is added to the repo history.
Once you have the output to your satisfaction, you can update again to the tip of development via the same process and continue your work:
Right click on the tip of development.
Select "Update"
Check the "Discard local changes" checkbox
Click update
The benefit of using update over revert is that Tortoise will explicitly display the parent of the working directory as the changeset it history. Under revert it could be very easy to revert the files and lose track of which changeset you had reverted to and which part of history you occupied.
(This is assuming that you want to move to that point in the history. If you need to create a changeset that undoes a prior changeset, look into backout, though I'm not sure if that is available in Tortoise.)
You can select all modified files in the list with Ctrl+A and then select "Revert" from context menu.
I had two very large projects in my Mercurial repository.
I am in the process of refactoring both of them into smaller sub-projects.
That involves moving sets of sources from a parent project directory into a sub-project's sub-directory.
For most files, I simply moved them.
For some files, I also had to make changes.
Before I commit my refactoring changes, I would like to review any edits that I made to any source files. In the GUI tool SourceTree - it shows me any modifications (in addition to indicating that the file has been moved/renamed). Is there any way to determine what files have also been modified from the Mercurial command line?
Here is a specific example of what I am talking about:
iphonedev:EveryScape cdoucette$ hg status -C Engineering/iOS/ESSDK/src/ESSDK-Miscellaneous/ESDataManagerInMemory.m
A Engineering/iOS/ESSDK/src/ESSDK-Miscellaneous/ESDataManagerInMemory.m
Engineering/iOS/ESSDK/src/ESDataManagerInMemory.m
How can I compare the old revision with the current working copy in a different location?
If I just do this:
hg diff Engineering/iOS/ESSDK/src/ESSDK-Miscellaneous/ESDataManagerInMemory.m
It shows me the entire contents of the file (since technically it was added in its new location).
Instead, I want to diff between:
Engineering/iOS/ESSDK/src/ESDataManagerInMemory.m (repository copy - previous revision)
Engineering/iOS/ESSDK/src/ESSDK-Miscellaneous/ESDataManagerInMemory.m (working copy)
I did search for similar questions. This post was close - but appears to only make sense if I went ahead and committed my changes. Instead, I would like to find and review my changes before committing.
Mercurial diff not working after move/rename
I would script it up like this:
hg cat -r <oldrev> <oldfilename> > oldfile.oldrev
diff <newfilename> oldfile.oldrev
I need to extract a list of changed files from Mercurial from the last "revision" tag to the current working version instead of the head. The process is part of a batch script, so the current revision bit needs to be automated.
I know that I can get the current revision using:
hg id -n
or
hg parent --template "{rev}\n"
I also know that I can get a list of changed files from a tagged version ("from") like this:
hg st --rev from > file_list.txt
I also know that I can get a list of changed files from a tagged version ("from") to another tagged version ("to") like this:
hg st --rev from --rev to > file_list.txt
However, is there a tag or a way that one can specify the "to" version to be the current working version automatically? I need to be able to exclude the "tip" or "default" files.
This process happens in a DOS batch file, if that helps, and the results are all output to text files.
Sorry - I got confused about which files actually had changed... The answer is as simple as:
hg st --rev from > file_list.txt
That will list all files that have changed from the named revision to the current working version and NOT the head revision (tip or default).
I'd like to know the best/easiest way to get a visual diff of a file given two revisions in Mercurial. I.e., I'd like to visualize the difference between revision 3 and revision 12, etc.
If by 'visual' you mean a text comparison you can do:
hg diff -r 3 -r 12
If you want a GUI tools you can easily configure and use the ExtDiff extension, which comes with Mercurial, and use:
hg yourdiff -r 3 -r 12
where yourdiff was configured in your hgrc file.
In the 'better late than never' category, and in answer to epalm's comment, here is how to compare any two revisions of a file from within TortoiseHG.
From any view that displays the file of interest, right click on the file and select 'File History'. This will open a new window that only displays check-ins for that file. (If the file you want is not visible in the current change set, remember that all files are visible in the Manifest view.)
From the File History window, select the two revisions that you want to compare by doing a CTRL - Left Click on each one. Make sure exactly two revisions are selected or you won't see the context menu you need in the next step.
Right click on one of the selected file and choose the "Diff selected file revisions..." option. A file diff window will open with whatever diff tool TortoiseHG is configured to use.
Note that this answer was written based on TortoiseHG version 2.6.2