I am trying to clean up a repository using hg convert --filemap. Convert works fine with any option in filemap except rename. If I add any rename option to filemap then it fails at the first merge with abort: unable to convert merge commit since target parents do not merge cleanly.
I tried putting in filemap only a dummy rename foo bar option (none of the foo or bar paths actually exist in the repo) and I get the same result.
I tried putting in a real rename (existing 1st path), same happens. As fast as any rename gets in there, it breaks.
It this a bug? What am I doing wrong?
UPDATE: To reproduce:
Create file a, write something in it, commit. Update to parent, write something else in a, commit. Merge with other head, fix conflict by hand.
Filemap consists of one line and one line only: rename foo bar. Run hg convert. It will fail if the commit can't be automatically merged.
Can't reproduce error with filemap, defined according to extension wiki rules:
Original repo
Repo>hg log --style changelog
2019-08-17 Me
* file1.dat, file1.txt:
Merge all from Data1
[21caf63b7011] [tip] <Data2>
* file1.dat:
Compability fix
[77667c9ad22c] <Data2>
* file1.dat, file1.txt:
Mod for Data2
[7253bf25d7e7] <Data2>
* file1.dat, file1.txt:
Mod for Data1
[de1f80454b7b] <Data1>
* file1.dat, file1.txt:
Mod1
[7f1dd9e27ceb]
* file1.dat, file1.txt:
Initial tree
[d10d46c86e0f]
Converted repo
Conv>hg log --style changelog
2019-08-17 Me
* core.code, data.dat:
Merge all from Data1
[350d1675a713] [tip] <Data2>
* data.dat:
Compability fix
[7b13e52e0887] <Data2>
* core.code, data.dat:
Mod for Data2
[05f2eae8379c] <Data2>
* core.code, data.dat:
Mod for Data1
[6776b7ac4388] <Data1>
* core.code, data.dat:
Mod1
[c733197f909c]
* core.code, data.dat:
Initial tree
[19230ad05c7a]
Filemap
rename "file1.txt" "core.code"
rename "file1.dat" "data.dat"
I had the same error and I worked around it by splitting my conversion into multiple steps.
It seems like the problem is when you have a combination of renames in the filemap AND merges in the included history during a single run of convert. So I did this:
Step 1: run hg convert using a filemap with NO RENAMES. Basically just to include/exclude things from the original repository into a temporary intermediate repo.
Step 2: run hg convert again using a filemap that did only renames. This would go from the intermediate to final repositories. Even though merges were still in the history, no problems.
Delete the intermediate repository
This got around the "abort" problem. Also a secondary benefit was that since step 1 was the longest (it was picking only a few 100 changesets out of about 20000) it became much easier to iterate on the renames. I find that filemaps are a little hard to get right since things will just fail silently.
I was using "Mercurial Distributed SCM (version 5.7)"
Related
I have a branch with a few revisions in it. I want to try making some code changes that require reordering and patching those commits with histedit, but I want to keep the original branch around in case it doesn't go well. How can I do that?
Example
Before:
master -> change 1 -> change 2 (branch A)
After:
master -> change 1 -> change 2 (branch A)
-> change 1 -> change 2 (branch B)
The integrated and recommended way to copy or cherry-pick commits from one branch to another is using
hg graft -r XX YY ZZ.
where XX YY ZZ etc. are the revisions to copy to your currently checked-out branch. By default they are committed, but you can also use the --no-commit flag so that you can edit changes. Or do it one-by-one and make additions using hg commit --amend.
Compared to exporting and importing it has the added benefit of using the configured merge programme, should a merge be required - but it will NOT be a merge, so no line of ancestors is established from the current commit to the one you copy from.
My understanding is when we do a diff using mercurial it creates 2 temporary folders- one for each revision being compared against:
Mercurial/extdiff not changing to temp dir (as I THINK it's supposed to)
I know how to set up a external diff(say EXTDIFFTOOL) tool using the mercurial .ini file. My problem is: How can I let my EXTDIFFTOOL take 2 arguments: one each for the temp folders.
In my project, I haven't been using hg remove, hg mv or hg addremove due to ignorance. Consequently, every time I've renamed or moved a file, the history of that file has been messed up and now when I look at an individual file's history, I will only see a portion of the history.
What I'm looking for is a way to go back and retroactively fix all of those renaming mistakes so that the file history will stay together. What I imagine would be most likely is a way to edit the data in ".hg\store\data" to make this work. I've been experimenting, and I see the lines copy: and copyrev: in the data for the files I've renamed, so I suspect that has something to do with it.
Assume that I have control of the central repository and that there are no clones of it currently.
Summary:
Since you have full control of the repo this can be 100% fixed using normal hg commands.
The principle idea is to insert new changesets in the right places which effectively correct the original ones.
Let's say your history looks like this:
A-B-C-*
(* is your working folder)
and it was in B that you renamed a file in the filesystem without renaming it in hg.
Do this:
hg up A
hg revert -r B --all
hg mv oldfilename newfilename
hg commit -m <message>
The key here is using revert which is used to copy changes from a changeset into your working folder. This only works this way because you have updated to the predecessor of the changeset you are reverting.
at this point your history looks like:
A-B-C
\
B'-*
where B' is the "corrected" variant of B. Continue with:
hg rebase -s C -d B'
and you have:
A-B
\
B'-C-*
You can now clean up by doing:
hg strip B
leaving just:
A-B'-C-*
Of course where I used revisions like B you need to type the actual revision # or hash.
You could also use TortoiseHG or some other GUI to do a lot of these steps.
This answer covers the situation where you do NOT have full control of the repo. Its a little trickier and you can't get quite as clean of a result, but it still can be dealt with using normal hg commands.
The principle idea is to insert new changesets in the right places which effectively correct the original ones, and merge them after the fact.
Let's say your history looks like this:
A-B-C-*
(* is your working folder)
and it was in B that you renamed a file in the filesystem without renaming it in hg.
Do this:
hg up A
hg mv oldfilename newfilename
hg commit -m <message>
at this point your history looks like:
A-B-C
\
B'-*
where B' is the "corrected" variant of B. Continue with:
hg up C
hg merge B'
hg commit
and you have:
A-B-C-D-*
\ /
B'
If you look at the file history of the file in question, it will look something like this:
o D merge
|\
| o B' rename file
| |
o | B change where the file should have been renamed
|
o A some earlier change
/
o ...
|
o ...
So the history is all linked together for the file. Its just a little weird that B looks like it started from nowhere (because it actually did).
how do I open from terminal window only files with conflicts during git/mercurial merge in textmate/sublime text2 editors
You can use the following to open all files with git merge conflicts in sublime text:
git diff --name-only | uniq | xargs subl
I wanted to add another answer. git diff --name-only will give you all files that have diffs. This is why sometimes it will yield duplicate entries because it marks the file as "modified" as well as in a merge conflict state. Piping it into uniq is a good solution for this but git diff --name-only will also include files you might have purposely changed so it doesn't actually filter only files with merge conflicts. When you are in the middle of rebasing, this is probably not going to happen often though I would say in most cases #StephanRodemeier's answer works.
However, what you can do though is leverage the --diff-filter option which assigns a states to files. See more in the docs
--diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]
Select only files that are Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), have their type (i.e. regular file, symlink, submodule, …) changed (T), are Unmerged (U), are Unknown (X), or have had their pairing Broken (B). Any combination of the filter characters (including none) can be used. When * (All-or-none) is added to the combination, all paths are selected if there is any file that matches other criteria in the comparison; if there is no file that matches other criteria, nothing is selected.
It seems when files are in the both modified state, the diff status gets set to U (Unmerged) and M (Modified) so you can filter for only Unmerged files.
git diff --diff-filter=U --name-only | xargs subl
Should work without needing to pipe into uniq
Another thing you can consider is simply setting your editor as the difftool i.e. for VSCode documentation specifies how to do this by adding this to your .gitconfig
[diff]
tool = default-difftool
[difftool "default-difftool"]
cmd = code --wait --diff $LOCAL $REMOTE
I have recently encountered the need to generate a Mercurial diff of all changes up to a particular changeset which includes the first changeset of the repo. I realize this kind of stretches the definition of a diff, but this is for uploading a new project to a code review tool.
Let's assume the following changesets:
p83jdps99shjhwop8 - second feature 12:00 PM
hs7783909dnns9097 - first feature - 11:00 AM
a299sdnnas78s9923 - original app setup - 10:00 AM
If I need a "diff" of all changes that have been committed, the only way that I can seem to achieve this is with the following diff command...
diff -r 00:p83jdps99shjhwop8
In this case the first changeset in the argument param (here - 00) takes the regexp form of 0[0]+
This seems to be exactly what we need based on a few tests, but I have had trouble tracking down documentation on this scenario (maybe I just can't devise the right Google query). As a result, I am unsure if this will work universally, or if it happens to be specific to my setup or the repos I have tested by chance.
Is there a suggested way to achieve what I am trying to accomplish? If not, is what I described above documented anywhere?
It appears this actually is documented, but you need to do some digging...
https://www.mercurial-scm.org/wiki/ChangeSetID
https://www.mercurial-scm.org/wiki/Nodeid
So the special nodeid you're referring to is the 'nullid'.
2 digits may not be adequate to identify the nullid as such (as it may be ambiguous if other hashes start with 2 zeros), so you may be better off specifying 4 0's or more.
Eg: hg diff -r 00:<hash of initial add changeset> has resulted in the abort: 00changelog.i#00: ambiguous identifier! error.
I'm a little confused about what you need. The diff between an empty repository and the revision tip is just the content of every file at tip-- in other words, it's the state of your project at tip. In diff format, that'll consist exclusively of + lines.
Anyway, if you want a way to refer to the initial state of the repository, the documented notation for it is null (see hg help revisions). So, to get a diff between the initial (empty) state and the state of your repository at tip, you'd just say
hg diff -r null -r tip
But hg diff gives you a diff between two points in your revision graph. So this will only give you the ancestors of tip: If there are branches (named or unnamed) that have not been merged to an ancestor of tip, you will not see them.
3--6
/
0--1--2--5--7 (tip)
\ /
4
In the above example, the range from null to 7 does not include revisions 3 and 6.