[petsc-dev] Commit collision/corruption?

[Jed Brown]

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.

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




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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130306/0e7c1816/attachment.html>