Recently one of my coworkers grafted a commit that changed one (out of three) subrepositories on .hgsubstate. The graft instead changed all three to match the original changeset(even if they were changes from previous one):
changeset main:
f60c22f43d335e95a95301aee58a092b63800e4b external/a
26e615cf033cffa9fba77d2369e3802cc2b9a95e external/b
ca46ca7e5243439de09a2d14ffa60432c6c56d74 external/c
diff of changeset grafted:
7fe8fcdd7648e14bee5889a4b3155fde49f09de4 external/a
5b90cf021b0006c8681247a73e9940f835a959f4 external/b
-8479ff0a18dc684db7f0771ace700915c51e92e6 external/c
+69e97bdab56155fee6ab4d0d21bbf36b34b040f8 external/c
final graft:
7fe8fcdd7648e14bee5889a4b3155fde49f09de4 external/a
5b90cf021b0006c8681247a73e9940f835a959f4 external/b
69e97bdab56155fee6ab4d0d21bbf36b34b040f8 external/c
It seems that graft is replacing the file wholesale, not just it's specific changes. This is counter to my intuition of what graft should do. Worse, it's doing it even if i use -t internal:fail it doesn't let me merge anything.
I would at least like to know why that unfortunate merge is happening so we can avoid it in the future. I tried to reproduce the problem on a toy example, but i failed; since there are approximately 350 commits/merges separating both changesets, it's very likely i missed the problematic part.
My question is: Can i make mercurial output the steps it's taking to do this graft? Or somehow identify the source of the problematic merge?
A graft operation is a 3-way merge that uses the graft parent revision as the base. Nothing else in the graph should matter.
Source: https://groups.google.com/forum/#!topic/mercurial_general/3pHTx8gT208
It seems that my problem lies somewhere else, but I can close this question now.