<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 7:08 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 class=""><div class="im">Jed Brown writes:<br>
<br>
> On Wed, Mar 6, 2013 at 6:34 PM, Sean Farley <<a href="mailto:sean@mcs.anl.gov">sean@mcs.anl.gov</a>> wrote:<br>
><br>
>> > Run 'hg export de73c9a7d341d846b5e16a8d61a48'. Note how they do not exist<br>
>> > in the formatted patch. Why are they written into the commit?<br>
>><br>
>> I don't see this. I see contents for both of Barry's merges. You'll have<br>
>> to provide a test case where this happens to rule out gitifyhg.<br>
><br>
><br>
> Look for changes to src/mat/impls/aij/seq/ftn-kernels/*.h.<br>
><br>
> This all happened before I was involved.<br>
<br>
</div></div>You'll have to provide a test case. Also, all the petsc devs might as<br>
well use this time to upgrade their mercurial to the latest (2.5.2 at<br>
the time of this writing).</blockquote></div><br>I gave you instructions above, but here it is more verbosely.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">$ hg log -vr de73c9a7d341d846b5e16a8d61a48  |grep fsolvebaij.h</div>
<div class="gmail_extra">files:       src/contrib/style/checks/PetscFunctionBegin.sh src/contrib/style/checks/PetscFunctionBegin2.sh src/contrib/style/checks/PetscFunctionReturn.sh src/dm/impls/composite/pack.c src/dm/impls/plex/f90-custom/zplexf90.c src/dm/impls/plex/ftn-custom/zplex.c src/dm/impls/plex/plexcreate.c src/ksp/pc/impls/bjacobi/bjacobi.c src/ksp/pc/impls/fieldsplit/fieldsplit.c src/ksp/pc/impls/gamg/gamg.c src/ksp/pc/impls/openmp/hpc.c src/mat/impls/aij/mpi/mpiaij.c src/mat/impls/aij/mpi/mpiaij.h src/mat/impls/aij/seq/aij.h src/mat/impls/aij/seq/crl/ftn-kernels/fmultcrl.h src/mat/impls/aij/seq/ftn-kernels/fmult.h src/mat/impls/aij/seq/ftn-kernels/fmultadd.h src/mat/impls/aij/seq/ftn-kernels/frelax.h src/mat/impls/aij/seq/ftn-kernels/fsolve.h src/mat/impls/baij/seq/baij.h src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h src/mat/impls/dense/seq/dense.h src/mat/impls/fft/fft.h src/mat/impls/maij/maij.h src/mat/impls/mffd/mffd.c src/mat/impls/sbaij/seq/sbaij.h src/mat/utils/zerodiag.c src/snes/mf/snesmfj.c src/vec/vec/impls/dvecimpl.h src/vec/vec/impls/seq/seqcusp/cuspvecimpl.h</div>
<div>$ hg export de73c9a7d341d846b5e16a8d61a48  |grep fsolvebaij.h<br></div><div>$</div><div><br></div><div style>So fsolvebaij.h (and 9 other files) are not affected by the commit, but are named anyway.</div><div><br></div>
<div style>Recall that this is a commit that Barry made on his own, before I had anything to do with that branch. There was no rebase and no gitifyhg involved. If you strip that commit and 'hg import' what you just exported, you will get a different hash because those files that are named in the commit, but not affected by the commit, are no longer present.</div>
<div style><br></div><div style>Please show me in the hg specification for commits where it is allowed for a commit to name files that are unrelated to the commit and do not appear in 'hg export', but whose file names are part of the SHA1.</div>
<div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style>Editorializing, I believe that diffs are a cruddy way to archive state because it relies on the diff being normalized. The above conflict would be impossible with git because the sha1 represents content (not a diff). The sha1 cannot be different without the content being different. With hg, we have multiple ways to represent semantically identical commits because the binary diff representation is not normalized (it's possible for it to name files that are not affected by the commit). That is, a bug in Hg can create a commit like this (based on non-normalized diff), but a bug in Git cannot create a commit based on a non-normalized representation because the only representation is the content itself.</div>
</div></div>