[petsc-dev] Commit collision/corruption?

[Sean Farley]

Jed Brown writes:

> On Wed, Mar 6, 2013 at 7:08 PM, Sean Farley <sean at mcs.anl.gov> wrote:
>
>> Jed Brown writes:
>>
>> > On Wed, Mar 6, 2013 at 6:34 PM, Sean Farley <sean at mcs.anl.gov> wrote:
>> >
>> >> > Run 'hg export de73c9a7d341d846b5e16a8d61a48'. Note how they do not
>> exist
>> >> > in the formatted patch. Why are they written into the commit?
>> >>
>> >> I don't see this. I see contents for both of Barry's merges. You'll have
>> >> to provide a test case where this happens to rule out gitifyhg.
>> >
>> >
>> > Look for changes to src/mat/impls/aij/seq/ftn-kernels/*.h.
>> >
>> > This all happened before I was involved.
>>
>> You'll have to provide a test case. Also, all the petsc devs might as
>> well use this time to upgrade their mercurial to the latest (2.5.2 at
>> the time of this writing).
>
>
> I gave you instructions above, but here it is more verbosely.

No, I got that. I, and no other dev, can reproduce. What I was implying
is an error between the chair and the keyboard. Perhaps you didn't
realize you did a rebase or some other such human mistake.

> $ hg log -vr de73c9a7d341d846b5e16a8d61a48  |grep fsolvebaij.h
> 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
> $ hg export de73c9a7d341d846b5e16a8d61a48  |grep fsolvebaij.h
> $
>
> So fsolvebaij.h (and 9 other files) are not affected by the commit, but are
> named anyway.
>
> 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.
>
> 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.

Since I cannot reproduce this, I am skeptical of this being pure
mercurial. I posit that you, perhaps unknowingly, infected the tree with
gitifyhg (or rebase?).

We could be in some corner case of case-collision with a
case-insensitive file system but we'd need a pure mercurial test case.

> 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.

You have yet to prove this is a bug in mercurial and not from you. Hence
my earlier request for a complete test case.