[petsc-dev] Commit collision/corruption?

[Jed Brown]

On Wed, Mar 6, 2013 at 10:54 PM, Sean Farley <sean at mcs.anl.gov> wrote:

> Responding to this paragraph more in depth now; your information above
> is at best misinformed and at worse complete bs. Both mercurial and git
> store the sha1 representation with a binary-safe "diff" algorithm. Git's
> seems to be like xdiff and mercurial's is mdiff.
>

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.


> Let's look again at your original request, 'hg export de73c9a | grep
> fsolvebaij' shows no output. Well, that's because you're diffing against
> the wrong parent. Running 'hg export --switch-parent de73c9a | grep
> fsolvebaij' gives:
>
> diff --git a/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h
> b/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h
> --- a/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h
> +++ b/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h
>

So naming these files is optional?

changeset:   26388:de73c9a7d341
tag:         tip
parent:      26376:84182841dc78
parent:      26362:2c1d69e93258
user:        Barry Smith <bsmith at mcs.anl.gov>
date:        Tue Mar 05 16:55:25 2013 -0600
summary:     merge, terrible manual process with many conflicts with Jed's
PETSC_INTERNAL
$ hg export -r de73c9a7d341 > first-parent.patch

$ hg strip de73c9a7d341
99 files updated, 0 files merged, 40 files removed, 0 files unresolved
saved backup bundle to
/tmp/jed/petsc-hgbad/.hg/strip-backup/de73c9a7d341-backup.hg
$ hg up 84182841dc78          # first parent
89 files updated, 0 files merged, 40 files removed, 0 files unresolved
$ hg import first-parent.patch
applying first-parent.patch
$ hg log -r tip
changeset:   26387:4b474795bc4d
tag:         tip
parent:      26376:84182841dc78
parent:      26362:2c1d69e93258
user:        Barry Smith <bsmith at mcs.anl.gov>
date:        Tue Mar 05 16:55:25 2013 -0600
summary:     merge, terrible manual process with many conflicts with Jed's
PETSC_INTERNAL

$ hg log -vr 4b474795bc4d | grep fsolvebaij       # de73c9a7d341 included
the file name
$ hg export -r 4b474795bc4d | grep fsolvebaij    # no output, same as
de73c9a7d341
$ hg export --switch-parent -r 4b474795bc4d | grep fsolvebaij # also same
output
diff --git a/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h
b/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h
--- a/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h
+++ b/src/mat/impls/baij/seq/ftn-kernels/fsolvebaij.h

unbundling the original, I have

$ hg diff -r 4b474795bc4d:de73c9a7d341
$

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?

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


> Editorializing, I believe that you are wasting everyone's time with your
> constant (and mostly vacuous) complaining about mercurial. No one has a
> problem with this merge except for you. And, judging from your earlier
> emails, it was a problem for you after you ran it through gitifyhg. So,
> again, I say that this is a bug with your extension.
>

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