I can use hg log with either --stat or -p to see affected files and diff version for the revisions. Is there something like that for patches sitting in MQ ? I would like to see what changes would be brought by a particular patch without applying it first.
Patches which are under mq control but currently not applied are not part of the repository and as such cannot be accessed by the normal mercurial commands.
However the patches are stored as patch files in .hg/patches/ directory, and you can directly view the patch files. The series file lists the order in which the patches are going to be applied.
Related
I use a Mercurial Queues to create patches while I work on the repository.
So, let's say after I'm done with a patch, I do hg qrefresh and export the patch to some file I want.
So, now I have a patch file.
How do I view this visually view this patch, side by side , to know the changes I made to the original file(s) in the repository?
I know of one direct way: Keep copies of all the files before I edit and use kdiff3 or meld when I'm done. But this is clearly very time consuming and not straightforward.
If you still have the patch in MQ you can do a side-by-side view using the ExtDiff extension, which you already have installed but probably not enabled.
Then you'd:
hg extdiff .... -r revision_before_patch -r revision_including_patch
On the other hand if you want to be able to do it from just original files and a .patch file you'll need to find a diff program that takes an original and a patch instead of an original and a result. My (old!) favorite is xxdiff.
We have a master repository located on a separate server. I originally cloned the default branch and made my changes locally. I have locally commited those changes. However, there has been a branch created on the master repository that I would like to push my changes to. Below is the description of my attempt at getting this accomplished.
I have cloned the branch. I am trying to export my changes from local default like so:
C:\hg\default>hg export -g -o mypatch -r tip
and when trying to import them into the clone of the new branch, I get the following:
C:\hg\newBranch>hg import C:\hg\default\mypatch
applying C:\hg\Fill1\mypatch
patching file .hgignore
Hunk #1 FAILED at 11
1 out of 1 hunks FAILED -- saving rejects to file .hgignore.rej
abort: patch failed to apply
I can manually fix the .hgingore.rej file just fine. The problem is that the patch also contains files that were moved. Instead of the files showing as moved, I get the following when running hg status:
C:\hg\newBranch>hg status -C
M someOtherFilesThatLookAsExpected.txt
! originalLocaion\fileA.txt
? newLocation\fileA.txt
This missing and new status is for all files that were moved in the commit contained the applied patch. Am I doing something wrong? Do I always have to manually move files when applying a patch? Is there an easier way to accomplish this branch transfer?
That's a bit difficult to answer without knowing more about your repository structure, but here's how I'd go about it without knowing more. I'm assuming that the reason for the conflict is that there are conflicting changes in the same branch of the repository.
First, get the contents of the newBranch repository:
cd c:\hg\default
hg pull c:\hg\newBranch
Then, either merge or rebase your changes on top. If you are working on the same branch, then just using
hg pull --rebase c:\hg\newBranch
in lieu of the regular pull should do (assuming you have rebasing enabled). Otherwise, do an explicit merge or rebase of the two heads that you need to reconcile. Finally, do:
hg push -r tip c:\hg\newBranch
in order to get your (now reconciled) changes back into newBranch.
Unless you have very specific and unusual requirements, push and pull should be your normal way to sync repositories or part of them (note that using -r will only push/pull the respective branch). Export/import are rather low-level mechanisms that may not give you the benefits of the standard machinery that handles renames, three-way merging logic, etc.
Mercurial Queues is about patches, and patches know nothing about file renames. Is this the reason why Mercurial Queues don't support file renames, or am I doing something wrong renaming the file? I have worked on a patch queue modifying just one file called foo. Now I go back to patch 4 and rename the file via hg mv:
hg qpop 4 # Unapply all patches until patch 4.
hg mv foo bar # Rename file and led Mercuial know about it.
hg qrefresh # Should apply changes to unapplied patch 4.
hg qpush -a # Should apply all unapplied patches.
I get the following error:
unable to find 'foo' for patching
1 out of 1 hunks FAILED -- saving rejects to file foo.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh 5.diff
So how should I do to handle file renames with Mercurial Queues? Mercurial commits handle file renames for a reason (as without, it would lose the whole history about the editing of the file after renaming).
Update
Just noticed that hg histedit folding changesets and hg collapse also lose the information of file renaming, the file shows up as a new one instead of a renamed one, and I guess this is for the same reason. Seems like collapsing private changesets is not possible in Mercurial without loosing that information?
Update 2
Found out collapsing private changesets without loosing rename information is possible with hg rebase and its --collapse option, e.g. hg rebase -s 5 -d 4 --collapse. The issue that the other commands should sostain rename information is still vacant, but using the hg rebase command there is at least a way to achieve the desired result.
Is this the reason why Mercurial Queues don't support file renames,
no.
or am I doing something wrong renaming the file?
no.
Yes, patches in chain will have troubles, if they was prepared for foo file, but later in will be bar, but due to different reasons: patches are independent, and every and each patch know nothing about changes in others - they work with context, not with sequence of operations in separate patches. You done rename correctly, but this changeset invalidates later changesets, prepared on old content
I tried to update some files to old revision in many ways, but I haven't found yet.
(not permanently, just temporarily updating for testing)
For example, the following is OK in SVN.
svn up -r 100 foo.cpp
U foo.cpp
But in Mercurial, 'up' command doesn't permit file name argument.
Only is it possible to update entire source tree in Mercurial?
You'd have to use hg revert:
hg revert -r 100 foo.cpp
Note that this gives you local changes, as can be seen by running hg diff.
See hg help revert for more info.
This is fundamentally disallowed by Mercurial and other DVCSs. Both CVS and Subversion track which revision you have checked out on a per-file basis. You could have r1 of file x and r2 of file y. In a DVCs the entire repository is at a single version, which in Mercurial you can see with hg id.
As #Tom points out you can have modified files from different revisions, but if you want to see another revision without changes showing up you need to do the update in another clone (which given that local clones use hard links to be (a) instant and (b) space efficient) that's not much of a hassle.
I've just recently moved a lot of my Views and Controllers into more appropriate locations and am now wanting to pull down recent changes from our central repo.
I've done a hg pull which worked fine and asked me to do a hg update to bring the changes down locally. This in turn informed me that I needed to do a hg merge however when I try this, I get a message stating that
abort: outstanding uncommitted changes
When I check this using hg status I see in the list all of the files that I've moved (so they're now deleted from their old location).
How do I tell Mercurial that I've removed these files? Do I have to go through each one of them and manually do a remove? Is this something that's possible using only the command line rather than doing it with a GUI tool?
From the command line to automatically hg rm the files you've removed you'd:
hg addremove
It's likely your GUI (you didn't say which you use) exposes that functionality too.
However, that's not what's causing your message. You have some already made local changes that mercurial does know about (unlike the removed files which it doesn't know about until you tell it), and you need a hg commit before you can merge.