<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 10:54 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>Responding to this paragraph more in depth now; your information above<br>
is at best misinformed and at worse complete bs. Both mercurial and git<br>
store the sha1 representation with a binary-safe "diff" algorithm. Git's<br>
seems to be like xdiff and mercurial's is mdiff.<br></div></blockquote><div><br></div><div>In Git, the diff algorithm is irrelevant because it is not part of the SHA1. Git's SHA1 comes from a complete snapshot of the state, not a diff. Packing is an optimization that does not affect the user.</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>
Let's look again at your original request, 'hg export de73c9a | grep<br>
fsolvebaij' shows no output. Well, that's because you're diffing against<br>
the wrong parent. Running 'hg export --switch-parent de73c9a | grep<br>
fsolvebaij' gives:<br>
<br>
diff --git a/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h b/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h<br>
--- a/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h<br>
+++ b/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h<br></div></blockquote><div><br></div><div>So naming these files is optional?</div><div><br></div><div><div>changeset: 26388:de73c9a7d341</div><div>
tag: tip</div><div>parent: 26376:84182841dc78</div><div>parent: 26362:2c1d69e93258</div><div>user: Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></div>
<div>date: Tue Mar 05 16:55:25 2013 -0600</div>
<div>summary: merge, terrible manual process with many conflicts with Jed's PETSC_INTERNAL</div><div>$ hg export -r de73c9a7d341 > first-parent.patch</div><div><div><br></div><div>$ hg strip de73c9a7d341</div>
<div>
99 files updated, 0 files merged, 40 files removed, 0 files unresolved</div><div>saved backup bundle to /tmp/jed/petsc-hgbad/.hg/strip-backup/de73c9a7d341-backup.hg</div></div><div><div>$ hg up 84182841dc78 # first parent</div>
<div>89 files updated, 0 files merged, 40 files removed, 0 files unresolved</div><div>$ hg import first-parent.patch</div><div><div>applying first-parent.patch</div></div><div>$ hg log -r tip<br></div><div>changeset: 26387:4b474795bc4d</div>
<div>tag: tip</div><div>parent: 26376:84182841dc78</div><div>parent: 26362:2c1d69e93258</div><div>user: Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></div>
<div>date: Tue Mar 05 16:55:25 2013 -0600</div>
<div>summary: merge, terrible manual process with many conflicts with Jed's PETSC_INTERNAL</div></div><div><br></div><div>$ hg log -vr 4b474795bc4d | grep fsolvebaij # de73c9a7d341 included the file name<br>
</div><div>$ hg export -r 4b474795bc4d | grep fsolvebaij # no output, same as de73c9a7d341<br></div><div>$ hg export --switch-parent -r 4b474795bc4d | grep fsolvebaij # also same output<br></div><div>diff --git a/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h b/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h</div>
<div>--- a/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h</div><div>+++ b/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h</div><div style><br></div><div style>unbundling the original, I have</div><div style><br></div><div style>
$ hg diff -r 4b474795bc4d:de73c9a7d341</div><div style>$</div><div><br></div><div>So I have created a new commit that is semantically identical (parents, metadata, and merged content), but that does not name those extraneous files (as evidenced by 'hg log -v')? Is this ambiguity/non-reproducibility intentional?</div>
<div><br></div><div>At least 'hg import --exact first-parent.patch' fails saying that it cannot reproduce the same result. I don't understand why somewhat would design a system that has this sort of non-uniqueness due to superfluous information that is not represented in human-readable form (unlike 'hg bundle').</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>
Editorializing, I believe that you are wasting everyone's time with your<br>
constant (and mostly vacuous) complaining about mercurial. No one has a<br>
problem with this merge except for you. And, judging from your earlier<br>
emails, it was a problem for you after you ran it through gitifyhg. So,<br>
again, I say that this is a bug with your extension.</div></blockquote><div><br></div><div style>This commit has nothing to do with gitifyhg, but it is true that I would not have noticed the non-unique representation if not for gitifyhg. In the past, gitifyhg has always been able to reproduce Hg sha1s, even for very large repositories. It can't here because the SHA1 is literally not reproducible from the content (actual changes, metadata). If this is known/intentional, then perhaps the concept of having any external system talk two-way with Mercurial is wrong-headed. That would be sad.</div>
</div></div></div>