CODEWITHSUNDEEP
mercurialtortoisehg
mark
mark

Reputation: 62712

Corrupt hg log output, could it be true?

Please, observe:

c:\dev\shunra.old>hg log -r ecf --template '{files}' |tr " " "\012" | findstr ProductLicenseFeature

c:\dev\shunra.old>hg log -r ecf --template '{file_mods}' |tr " " "\012" | findstr ProductLicenseFeature
Application/ShunraLicense/src/com/shunra/common/license/ProductLicenseFeature.java

c:\dev\shunra.old>

So, what do we have here? ecf is the prefix of a revision, which is the result of merging two other revisions:

c:\dev\shunra.old>hg parents -r ecf --style compact
2430:2420   94067e763d55   2013-01-14 12:17 +0200   gilad
  Marge changes from S4HP9.0 branch

2443   a8f3e0a226eb   2013-01-15 00:48 +0200   genkor
  For empty locations and configurations take default content from templates.


c:\dev\shunra.old>

The merge was done in TortoiseHg. The strangest thing is that the particular file is not displayed in the change list, which corresponds to the {files} template keyword.

But it was changed, and indeed the {file_mods} template keyword does show it.

The net result is that we cannot trust the change list presented by TortoiseHg, which is a bad thing.

What is going on?

Upvotes: 0

Views: 87

Answers (1)

Vadim Kotov
Vadim Kotov

Reputation: 8284

Take a look at this thread. Maybe this file was automatically resolved during the merge? Quote from there:

A (automatic) merge will from one point of view not introduce any file
changes - only propagate changes that already has been made. From
another point of view it will introduce a number of "new" file changes
in another context and thus changes a lot of files. An intermediate
point of view is when both sides of a merge touches the same file and
the merge thus produces a combined file where the total content will be
new and unique.

Upvotes: 1

Related Questions