<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 7, 2013 at 11:06 PM, Sean Farley <span dir="ltr"><<a href="mailto:sean@mcs.anl.gov" target="_blank">sean@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Are you really trying to compare a representation of merge using a<br>
format that was never designed to handle a three-way merge?<br></div></blockquote><div><br></div><div>To start with, hg export cannot represent the difference.</div><div><br></div><div><div>$ diff <(hg export -r 84df07d03c6e) <(hg export -r de73c9a7d341)</div>
<div>4c4</div><div>< # Node ID 84df07d03c6e55bd0f27bd5ee8c1738562bd529d</div><div>---</div><div>> # Node ID de73c9a7d341d846b5e16a8d61a48242f0521c02</div><div>$ diff <(hg export --switch-parent -r 84df07d03c6e) <(hg export --switch-parent -r de73c9a7d341) </div>
<div>4c4</div><div>< # Node ID 84df07d03c6e55bd0f27bd5ee8c1738562bd529d</div><div>---</div><div>> # Node ID de73c9a7d341d846b5e16a8d61a48242f0521c02</div><div><br></div><div>Digging deeper</div><div><br></div>
<div>$ diff <(hg manifest --debug -r 84df07d03c6e) <(hg manifest --debug -r de73c9a7d341)</div><div>902c902</div><div>< 402038908c312f83748dae2fffdb4d699b35663f 644 src/dm/impls/composite/pack.c</div><div>---</div>
<div>> 154f020ddb26968c2e1002aaf63972aa82f6427b 644 src/dm/impls/composite/pack.c</div><div>[...]</div><div><br></div><div>$ hg debug-diff-tree 84df07d03c6e de73c9a7d341 </div>
<div>:100664 100664 402038908c31 154f020ddb26 M src/dm/impls/composite/pack.c src/dm/impls/composite/pack.c</div><div>[...]</div><div><br></div><div>Okay, this is progress. But how do we determine what is different</div>
<div><br></div><div>$ diff <(hg cat -r 84df07d03c6e src/dm/impls/composite/pack.c) <(hg cat -r de73c9a7d341 src/dm/impls/composite/pack.c)<br></div><div>$</div><div><br></div><div>(Same for all the others.) Unfortunately, the internals are basically undocumented and I haven't found the exact algorithm used to compute these file hashes. Do you know to tell what makes these hashes different, and why none of the user-facing commands seem capable of showing the difference?</div>
<div><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
<br>
Let's look at something git did after a 'git stash pop':<br>
<br>
diff --cc src/libmap/mapclientrpc.c<br>
index b0e3a2f,bb06b5d..0000000<br>
--- a/src/libmap/mapclientrpc.c<br>
+++ b/src/libmap/mapclientrpc.c<br>
<br>
You would think that this would delete mapclientrpc.c but it didn't!<br>
<troll>If 'git stash' stored things in a canonical format instead of as<br>
diffs, this would be impossible!</troll><br></div></blockquote><div><br></div><div>'git stash' creates a normal commit object, reachable from refs/stash (.git/refs/stash). You'll have to provide context if you want to claim something is inconsistent.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
> So I have created a new commit that is semantically identical (parents,<br>
> metadata, and merged content), but that does not name those extraneous<br>
> files (as evidenced by 'hg log -v')? Is this ambiguity/non-reproducibility<br>
> intentional?<br>
><br>
> At least 'hg import --exact first-parent.patch' fails saying that it cannot<br>
> reproduce the same result. I don't understand why somewhat would design a<br>
> system that has this sort of non-uniqueness due to superfluous information<br>
> that is not represented in human-readable form (unlike 'hg bundle').<br>
<br>
</div>I don't understand why you aren't looking this information up for<br>
yourself. You completely misunderstand how Mercurial is computing the<br>
SHA1 (hint: both Git and Mercurial are based on the same scheme [1]).</div></blockquote><div><br></div><div>That is a high-level paper that does not provide details. Compare to this chapter, for example, that explains how git objects are constructed, including stand-alone code to reproduce it.</div>
<div><br></div><div><a href="http://git-scm.com/book/en/Git-Internals-Git-Objects" target="_blank">http://git-scm.com/book/en/Git-Internals-Git-Objects</a><br></div><div><br></div><div>The git man pages also explain this in great detail.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div> If<br>
you commit a changeset with _exactly_ the same contents (including file<br>
hashes, user, date, extra fields...), you will get the same SHA1.</div></blockquote><div><br></div><div>Can you show why the file hashes above are different, despite the files having the same contents? See also this thread showing that the representation has historically been under-specified and handled inconsistently, thus you can't always reproduce old SHA1s using a newer version of Hg.</div>
<div><br></div><div><a href="http://selenic.com/pipermail/mercurial/2011-June/038828.html" target="_blank">http://selenic.com/pipermail/mercurial/2011-June/038828.html</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div> Git<br>
and Mercurial both store deltas,</div></blockquote><div><br></div><div>Until 'git gc' runs (possibly automatically), Git does not use deltas.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div> and they both compute SHA1s of commits,<br>
but the two computations are unrelated.<br></div></blockquote><div><br></div><div>What is the exact algorithm used to compute Hg SHA1s?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div>
> This commit has nothing to do with gitifyhg, but it is true that I would<br>
> not have noticed the non-unique representation if not for gitifyhg. In the<br>
> past, gitifyhg has always been able to reproduce Hg sha1s, even for very<br>
> large repositories. It can't here because the SHA1 is literally not<br>
> reproducible from the content (actual changes, metadata). If this is<br>
> known/intentional, then perhaps the concept of having any external system<br>
> talk two-way with Mercurial is wrong-headed. That would be sad.<br>
<br>
</div>The first changeset, which is a merge, made by Barry is perfectly<br>
fine.</div></blockquote><div><br></div><div>Yet 'hg import --exact' cannot import it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div> Your gitifyhg machinery seems to be the culprit of borking the<br>
second commit due it using private Mercurial's internals. Look around 20<br>
or so lines below line 763 of gitifyhg:<br>
<br>
<a href="https://github.com/buchuki/gitifyhg/blob/master/gitifyhg.py#L763" target="_blank">https://github.com/buchuki/gitifyhg/blob/master/gitifyhg.py#L763</a><br>
<br>
I'm guessing gitifyhg blindly passed a list of files (which happened to<br>
be in the diff of the first parent but were empty) and sent them to<br>
memctx. Who knows. Nor do I really care enough to dig deeper into the<br>
gitifyhg code. The point is, you are already in the land of calling<br>
internals of Mercurial, and therefore, you take the risk of bypassing<br>
checks that are in place for calls coming from the command-line. This is<br>
the price of admission for using internal calls (and not, say, the<br>
command server).<br></div></blockquote><div><br></div><div style>'hg import' also produces a different representation of that commit. Why is it so difficult to produce a human-readable representation of the difference?</div>
<div style><br></div><div style>(If you want to say gitifyhg did something wrong, you should provide evidence that something is actually wrong, not just that you don't like the code. Also, if there is a better way to create hg commits without using a working tree, please refer me to the documentation on how to do that.)</div>
</div></div></div>