When mercurial reports that it has merged files, how do I get the list of those automatically merged files? Is there a way to see this?
Sure, there are plenty. Mercurial doesn't commit that merge for you, so you can see what was modified using just:
hg status
If you want more detail you can use
hg resolve --list
Related
I have two branches let's say A and B. I have done few changes in A and committed my code into A then i have merged A into B and did a push.
Now the problem is i have added some unnecessary files into B.
I want o revert to a prev version of B. I have see few solutions to perform hg update -r and then forcefully push it to the repo which might lead to new heads which i don't want to do.
Bare me for the explanation, doing this for the first time. Thanks.
I want to revert back to 3313 revision
you can go on your head, remove the unnecessary files, commit and push.
Go to your branch B
hg update -r 3316
Remove the files, commit and push
hg forget yourfilethere
hg commit -m "Remove unecessary files"
hg push
let me know if it helps!
If what you want is to remove or modify a pushed revision, then I am afraid Mercurial (by design) does not support this. (You can change the phase of a revision to 'draft' and strip or amend it, but when you pull again the old revision will re-appear.)
If you really need to remove the revision (e.g. it contains some huge files), then there is nothing you can do about it on your local repository; the only way this can be done is on the remote repository (e.g. having the administrator run hg strip directly on the remote repository, or some equivalent thereof; the BitBucket interface does support stripping a revision).
We have had a similar problem at work, where some user committed very large files to the repository, and a lot of work was done on the repository afterwards. The only way we were to solve it was using the 'convert' extension to remove the files, and then pushing into a brand new repository. (If we had just pushed the converted repository to the existing one, this would just have created duplicate revisions starting from the point where the bad files were committed.)
In mercurial, the merge ignored some files (possibly a human mistake). How I can 're-include' the ignored files?
Scenario: the merge target(rev #47) has 5 files, but the merge(rev #50) has included just 1 file and others are ignored.
Apparently, when I check the resulting code, the code from Rev# 47 is missing.
You probably did the merge in a way you didn't intend, e.g. telling hg to only accept changes from one branch, discarding the changes from the merged rev47.
The easiest way is to start with a repo where the merge did not happen and re-do the merge. This is not possible, if it is a shared repo and that merge is already shared with others. If it everything local, but if that repo is your only copy, make a new clone without the merge: hg clone -r49 OLDREPO .
Thus if you cannot simply re-do the merge on a new repo without that merge, you'll have to go a longer way which is summarized in this answer. Note the screenshot in the accepted answer and DO NOT discard the changes from the merge target.
How to checkout a single file from one branch to another in Mercurial?
Basically I want to copy a single file from a branch experimental to another branch production.
You can show any file at any revision with hg cat -r experimental filename. But this kind of behavior looks like a debugging patch, in which case I would consider transplanting (cherry-picking in other DVCS).
hg revert -r experimental filename could do it, not tested.
hg revert as suggested by #shellholic will indeed create a file from one branch in another branch. However the file will look as freshly added in history. Its actual history is not shown in the target branch.
I find grafting a better alternative.
Let's assume you have 2 branches, and you have created and worked on file f2.txt in the side branch. You were also working on the file f3.txt in the same branch at the same time.
Create another changeset in the source (side) branch, this changeset containing only the file you are interested in. If you already have such changeset, use it, no need to create a new one.
Update to the target branch.
Graft the source changeset. Mercurial will ask you if you want to use the changed version. Answer "c" (changed).
The result looks like this:
the file history is correctly preserved:
and f3.txt is not merged into the target branch.
I want to know what changes I made, without looking at the 30 other files that other team members modified.
So when I hg out, it said the first changeset to push was 4821, so since then I have pulled, merged, and pushed a couple times. Now I want to make sure all the debugging code is removed. Is there a way to diff the current revision (4873) against revision 4821 but only for my changes?
If your changes are in different files than those of your coworkers, which is how it sounds, you can use something like this:
hg diff -r 4821 -r 4863 -I path/to/file1 -I path/to/file2
If they're mixed in the same files as other people's changes then you would have needed to keep your changes in a separate branch (which doesn't require the branch command, anonymous branching is commonly used for this sort of thing).
The following command should do the trick:
hg diff -r "4821:4873 and user(your_username)"
I don't know if you can upgrade to the recently release Mercurial 1.6 or not, but this functional query language feature they just put in is what you might be looking for.
Try this approach:
First clone your local repo to another folder
In the new clone, rebase your last changeset so that it immediately follows your the other changeset (this should create a new head from it)
Do the diff
I'm using Mercurial. What exactly does hg pull do and what other steps need to be in my workflow after I use it?
The main clone is called "farm". I made a clone of it called "myfarm" which I've been developing locally. Now I want to push the changes from my clone to the real clone hosted at googlecode.
So in the context of my own clone "myfarm", I run [hg incoming farm]. This seems to list all the changes that have been made to "farm" since I made my clone of it. Lists a bunch of stuff like:
changeset: 545:edfe4dadf
parent: 549:ea8e55929bcF
parent: 592:dfdf05dbcfA3
user: Some user
date: Some date
summary: Some comments
ok so then I ran [hg pull farm]. I'm left with the following at the command prompt:
pulling from https://blah.googlecode.com/hg
searching for changes
adding changesets
adding manifests
adding file changes
added 6 changesets with 3 changes to 2 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
Questions:
Is everything merged for me already, or do I need to run hg merge farm now?
How will I know if there are conflicts? If so, I'm also not sure if I have to run:
.
hg merge farm
hg merge
I mean, I want to merge the results of the pull, but am not sure which of the above two is appropriate.
I'm used to using svn, so in this case, I would have just done:
svn update (notified of merge changes)
svn ci
Thanks
In the case you've described, you would run hg merge. pull is just a synchronization step, it doesn't modify the local working folders not add any merges or so any other real work.
Joel Spolsky has recently published a good tutorial on version control with Subversion at http://hginit.com. I would suggest having a read through this if you're still not quite up to speed with the concepts. I would recommend reading through the tutorial sequentially (rather than skipping to the "Merge" page) because the examples he uses build upon one another and will be easier to follow if you've read the previous sections.
Hg has an svnbook too.
Chapter 3 clearly explains your problem.
hg merge is indeed what I would do.