Mercurial: merging a randomly created subfolder

TL; DR: It seems I created a separate repository in a subfolder of my main project. How to combine them?

I have a project folder, let her name BOB. I cloned ( hg clone ) BOB to a new BOB2 folder. 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 a lot of checks.

Today I realized that somehow I created a separate repository for BOB-newfeatures (I have not changed anything on the BOB2 homepage until today, so I did not notice that the changes were not tracked). If I do hg status on BOB2, it does not know about changes in the subfolder and vice versa.

Is there any way to stitch them together? I know that I could hg add all the files in the BOB-newfeatures for BOB, but then I think that I will lose the whole history of my testing.

+1
mercurial
source share
2 answers

OK, I reconstructed (hopefully) your case with your names, starting with

 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 an additional confirmation of the invisibility of BOB-newfeatures inside BOB2

 BOB2>hg manifest 1.txt 2.txt Sub/3.txt 

The method for solving the problem is using the Convert extension with --filemap in the opposite direction compared to the Wiki: this is an example of transform subdir repo into a separate repository, I will transfer the root of the repository to a subfolder

  • map-file prepared for conversion
 rename . BOB-newfeatures 
  • transformations
 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 
  • Test 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 path files with the log from the embedded repo, mark different hashes for changesets

  • The next bad news: you can't just pull it out of BOB | BOB2 to the missing parts converted repositories.
 BOB-newfeatures-conv>hg pull ../BOB2 pulling from ../BOB2 searching for changes abort: repository is unrelated 

Even with -force (because the repositories are really not connected and do not share history), you will get a "dirty" combined repository (changes in the root and in BOB-newfeatures/ are two separate lines of changes with their 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) 

Force pull result

And at the last step you need to translate two stories into one common. In my case, due to my actions (pulling BOB-newfeatures history into a converted repository with an existing history) I had to refer to versions 0-1-2 after 3-4-5 (historically earlier changes) and I don’t know a more elegant way do it than convert the (HG-> HG) repository --splicemap , --splicemap this time

With the release of the magazine

 >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 oneliner format "ChildHash ParentHash")

 da27a50a5cb6246c03c6af7485ac7ffc33e62738 25a16a8fea5e5b4dac42a0a6b2c8e82890c220a3 

and the last conversion is done

 >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

Final repo

+2
source share

You just created a separate repository. As such, you can pull from this repository, as from any other. In this case, in your main repository in BOB2 you can do:

 hg pull ./BOB-newfeatures 

To avoid confusion, I first moved BOB-newfeatures to the same directory level as BOB2, and then pulled out a new relative path. / BOB -newfeatures; but it’s more for cosmetics and for keeping your BOB2 repository; strictly speaking, this is not necessary.

(Basically you used the hg function: you can create a new repo in any subpath that will be an independent repo that does not know anything about the parent and vice versa. It was used, for example, for libraries that are needed for the main repo but which you do not want to link directly with your main and then are in the expected relative path and easy to work with)

+1
source share

All Articles