I've worked on some project. I'm able to see the difference between my project and its (sole) parent with:
hg kdiff3
(After I've configured "kdiff3" as shown here). However, I want to be able to edit my files, perhaps remove some of my changes, edit some of them or make new changes. But that command only shows me the differences, rather than let me edit them. If I try:
hg merge 5861231e8335
(When "5861231e8335" is the (sole) parent of the working directory) I get:
abort: merging with a working directory ancestor has no effect
So how can I "merge" with the parent? (preferably using "kdiff3")
First, you have misunderstood what hg merge does. It merges changesets from 2 parents. It doesn't merge uncommitted changes.
To merge uncommitted changes into the current tip changeset, you want:
hg commit --amend
which replaces the current tip with a new one.
To answer your question about editing in a differencer. I'm not aware of any method of editing a bunch of files in a file differencer; that's because the set of files get copied into the temp directory where it's obviously pointless to edit them. You can however, diff and edit one file at a time because one file is diffed in place without copying to the temp directory.
But surely, isn't it better to edit files in your normal editor rather than in a file differencer? Surely, one can edit, but only as a last resort. OTOH, if you use the trick of viewing diffs one file at a time, it is possible to edit in your real editor, then watch the diffs change in the differencer.
hg shelve lets you temporarily put aside (on a shelf) parts of the diff between the working directory and its parent, so it will give you the "remove some changes" part of what you want. It does not let you edit, but you could put what you have changed on one shelf, then reimplement the change. If you want to revert to the original change, you just put the new change on a new shelf, and pull the original change off its shelf.
Alternatively, create a copy of the parent changeset using hg export (or hg clone and update to the parent changeset, but you don't need the history for this), Once you've got your copy, you can merge the copy of parent with your working directory using kdiff3 directly, outside of Mercurial.
Related
Doing a git merge master on a branch, and conflicts are usually displayed in a file as follows:
<<<<<<< HEAD
=======
>>>>>>> master
In Visual studio, you get an option to Accept Current Change | Accept Incoming Change | Accept Both Changes.
Now I want to accept both changes, however, they are in the wrong order. If only the master's change was first, then they would be in the right order and I wouldn't need to move things around.
Have many such conflicts and looking to see if I can somehow display the master's change above HEAD's, and thus enable a quick Accept Both Changes resolution.
Any way to do this?
I have a question about the Meld visual diff and merge tool, which is probably a simple misunderstanding.
But how do I adopt lines that were removed in the $REMOTE?
Please see the screenshot below for an example. I have changed the order of the imports and created a merge conflict, so now I want to pull the first change from the right, but then also the second change that would remove those lines that now already exist at top of the imports. I could remove them manually of course, but surely there is an easier way?
Or am I wrong with my assumption, that the middle pane is the result that gets written to $MERGED?
Edit: In this contrived example, I actually have a Delete action that I can use to remove those lines. But in a real-world merge I'm trying to do with meld the Delete action is greyed out, as is the Pull from Right action.
Any idea why Meld wouldn't allow me to Delete those lines that will be made obsolete by a Pull from Right above them?
I found out that holding the Shift key allows me to remove individual changes.
Assume I have these two directories
/root/subdir1
/root/subdir2
and a perforce workspace with an overlay, like
Root:
/root
View:
//depot/project/... //workspace/...
+//depot/project/subdir2/... //workspace/subdir1
where subdir2 is overlaid on top of subdir1.
At some point I branch (integrate) a file from subdir1 to subdir2, and both files keep being changed and submitted to perforce, either on the overlaid workspace, thus under subdir2 or on another non-overlaid workspace, thus changing the file in subdir1.
How do I now merge (integrate) the files such that only the file on the non-overlaid workspace exists?
If I merge into the non-overlaid workspace and delete from the overlaid workspace, the file no longer shows in the overlaid workspace. If I don't delete it, the version before the merge stays there in the overlaid workspace.
For tasks like this, it can be much easier to use a workspace which has no overlay lines in its view mapping. Then it's not so confusing about which repository file corresponds to which local file, and you can refer to all the different repository files without dealing with the filename ambiguities introduced by overlay mappings.
Also, have a look at 'p4 where'; it gives you a lot of information about how a particular file in your workspace is mapped into its corresponding repository location.
This is one of the drawback of using overlays in workspace view specification: Order matters.
If when you apply an overlay, a file has been deleted in this overlay, on top of a folder where this file exist, then the existing file will never show up.
There is nothing you can do about it, as this is the perforce logic of how folders are populated.
You can try to fiddle with you view paths:
//depot/project/... //workspace/...
+//depot/project/subdir2/... //workspace/subdir1
+//depot/project/subdir1/... //workspace/subdir1
And you will see your integrated file back.
Overlays are great, but then moving/deleting files can mess up with them.
Note that if you rename the file as you move it from directory, then you won't have the problem. I.e. if you move/rename a file from:
//depot/project/subdir2/my_file_in_dir2
to
//depot/project/subdir1/my_file_in_dir1
And then apply your overlay:
//depot/project/... //workspace/...
+//depot/project/subdir2/... //workspace/subdir1
It's OK, as they don't share the same name anymore.
How can I discard remote changes in binary files when merging? There is only menu item to discard changes in local file. When I'm trying to "resolve" it tells it can't do that thing for binary file.
Sorry, I've mentioned "resolver" menu but it was "conflict solver". Log http://pastebin.com/xhGuc3du.
Although when I'm using "resolve" I see OK icon in the operations log (right bottom corner) but "conflict" label does not disappear. Log http://pastebin.com/DEDWQSht.
To discard remote changes, Local|Discard should be sufficient. To set your local content either to your own version before the conflict ('ours') or to the remote version ('theirs') use Local|Resolve and select the corresponding option there.
First, I used "update to revision" to update one of my directories to an old revision because we had to undo some changes.
However, when I go to commit now, It is stating that items of my project are out of date and that I should try updating.
However, I really don't want my current files to be replaced by any "newer" files in the revision.
I would like this commit to jump ahead and be the head revision.
Any tips?
Thanks
What you want to do is called a "reverse merge". Update your working copy to head, then perform a reverse merge to the revision you desire. There is a section in the SVN book about it here, under the "Undoing Changes" section.
For example, if you are at revision 412, but you want to back up to the contents of revision 410, use something like the following:
svn merge -r 412:410 http://yourrepository/trunk
This will get your working copy to reflect the state at 410, and then you can do a commit.