[petsc-dev] Commit collision/corruption?

[Sean Farley]

Jed Brown writes:

> On Wed, Mar 6, 2013 at 8:15 PM, Sean Farley <sean at mcs.anl.gov> wrote:
>
>> 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
>>
>
> If you say you cannot reproduce, please show the output of the above
> command.
>
> It's obvious that it names files with zero changes in the web interface
> (see attached pic). Bear in mind that Barry made this commit. Barry uses
> vanilla Hg so it was produced by Hg core.
>
>
>> > 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.
>>
>
> This *is* pure mercurial. All relevant commits were made by Barry. (He is
> not to blame, but I want to make it exceedingly clear that I was not
> involved in the creation of this "bad" commit.)

This is what I'm skeptical about. Starting from an empty repo, you'll
need to show the commands of what generates this bad merge.