[Insight-developers] Dashboard looks bad today

[Brad King]

On 11/19/2010 07:46 AM, Gaëtan Lehmann wrote:
> I've just commited the fix.
>
> I still don't know how the pointer to the right ITKData commit was
> lost - any idea?

I figured it out.  Here is a detailed explanation.  Skip to the end of
the message to see what I've done about this.

----------------------------------------------------------------------

The correct value is 48e77d62 and was merged correctly by commit
14f56723.  I just did some digging in history to see when the
backwards submodule data reference was merged into master.  I started
with a list of the changes in master between 14f56723 and the commit
that fixed it, e4dcfe60:

$ git rev-list --first-parent 14f56723..e4dcfe60 |
  while read rev; do
    echo -n "$rev: "
    git rev-parse $rev:Testing/Data
  done
e4dcfe60760062f9f5b16384f0e41df054fc5c98: 48e77d62ed7e09aacd1496f5881e7379654df13a
4c8a17195da7d1cf59fee17d7cc3711037d8b617: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
ee2bb1aa67bd1bb5057f188d26e8c3c1b60ff6e0: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
80ec5c60303855aa5479ee256f7a81b546d446a2: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
2ffcbf76db6a8422a1a5dd8dfb8cc71d01e8e3b3: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
c8608d91fda3b57592d8e0edabc9d4964281415f: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
68018da2cc1d41d8f5e243e195275bcc7c76e26a: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
705d68cc473a2035b985303458ac137732db5991: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
84a616034407181861352e96753291e6ac251e6e: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
c3c05dc6b839c7dd451f2c4db5a1589143893221: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
a6a894e4b4c90c64e1394dc6fac7b93626cca5a8: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
82b68e74957f3430b47135565735433b01872764: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
f2ba5746922a9c1b7c32e4423c057192ee92352c: a159c8d3a842bffa2a5fc57513a1eb433d3784bd
9fe91174818a6579b463998184371915c19309b8: 48e77d62ed7e09aacd1496f5881e7379654df13a
a41216012dc36a50d4c159fa4d349a048149f129: 48e77d62ed7e09aacd1496f5881e7379654df13a
...

So, we see that commit f2ba5746 is where the data were reverted:

$ git show f2ba5746
commit f2ba5746922a9c1b7c32e4423c057192ee92352c
Merge: 9fe9117 e100812
Author: Kent Williams <norman-k-williams at uiowa.edu>
Date:   Wed Nov 17 18:08:43 2010 -0500

    Merge topic 'MetaIO-Read-Write-MetaData-Resolve'

    e100812 Merge branch 'master' into MetaIO-Read-Write-MetaData
    5cf18a6 BUG10275 Added code to save/restore arbitary MetaData in MetaIO

Before f2ba5746 on master was its first parent, 9fe9117, which had
the correct reference 48e77d62 at Testing/Data.  Clearly the change
came from e100812:

$ git rev-parse e100812:Testing/Data
a159c8d3a842bffa2a5fc57513a1eb433d3784bd

Confirmed.  It has the old value.

$ git show e100812e
commit e100812ecf6b241597f01b6e5fde6da8319598ce
Merge: 5cf18a6 9fe9117
Author: Kent Williams <norman-k-williams at uiowa.edu>
Date:   Wed Nov 17 17:06:47 2010 -0600

    Merge branch 'master' into MetaIO-Read-Write-MetaData

    Conflicts:
        Code/Review/itkTxtTransformIO.cxx

    Change-Id: I3a93a334ecaf119a1b3d3489ad98881cd1b6d9bb

Let's compare the Testing/Data reference in commit e100812 with each
of its parents:

$ git diff e100812e^1 e100812e -- Testing/Data

No different from first parent.

$ git diff e100812e^2 e100812e -- Testing/Data
diff --git a/Testing/Data b/Testing/Data
index 48e77d6..a159c8d 160000
--- a/Testing/Data
+++ b/Testing/Data
@@ -1 +1 @@
-Subproject commit 48e77d62ed7e09aacd1496f5881e7379654df13a
+Subproject commit a159c8d3a842bffa2a5fc57513a1eb433d3784bd

Aha!  This is where it moved backwards.

While resolving a conflict Kent accidentally reverted the value of
Testing/Data.  Since the value in the merge commit matches at least
one of its parents, Git does not consider this a change by the merge
commit (so "git log -- Testing/Data" does not show it).

Here is how it happened.  I can reproduce it like this:

$ git branch left e100812e^1
$ git branch right e100812e^2
$ git checkout left

Now 'left' represents the topic "MetaIO-Read-Write-MetaData" on which
Kent was working, and 'right' represents the "master" branch at the
time.  The topic stage reported conflicts when he asked it to merge
the topic to master, so he followed the instructions and merged master
into his topic first:

$ git merge right
Auto-merging Code/IO/itkMetaImageIO.cxx
Auto-merging Code/Review/itkTxtTransformIO.cxx
CONFLICT (content): Merge conflict in Code/Review/itkTxtTransformIO.cxx
Automatic merge failed; fix conflicts and then commit the result.
$ git status
# On branch left
# Changes to be committed:
...
#       modified:   Testing/Data
...
# Unmerged paths:
...
#       both modified:      Code/Review/itkTxtTransformIO.cxx
...
# Changed but not updated:
...
#       modified:   Testing/Data (new commits)

So, we see that a change to Testing/Data has been correctly staged for
commit.  The change came from the 'right' of the merge:

$ git log left..right -- Testing/Data
commit 04d85fe5f0e155176877de6048640b9ed3ff93e2
Author: Luis ibanez <luis.ibanez at kitware.com>
Date:   Fri Nov 12 17:30:36 2010 -0500

    BUG:10443. New baselines needed.

At this point we should run "git submodule update" to update the work
tree copy of Testing/Data to reflect this change.  Watch what happens
if we don't.  We resolve the conflict:

$ edit Code/Review/itkTxtTransformIO.cxx

and stage the whole work tree for commit:

$ git add -u
$ git status
# On branch left
# Changes to be committed:
...

Uh-oh, the change to Testing/Data that had been merged in is gone!
This is because the "git add -u" updated the index with what it saw in
the work tree.  Since we didn't run "git submodule update" earlier the
value it got from the work tree was the *old* value!  After this the
procedure continues:

$ git commit
$ ...

and we have created a commit equivalent to what happened in e100812e.

----------------------------------------------------------------------

There are 2 ways this can be avoided:

(1) Run "git submodule update" after "git merge" in case the merge
brings in any submodule changes.

(2) Never use "git add -u" or "git commit -a" while resolving
conflicts until the output of "git status" reports exactly what you
want to see.  Alternatively just "git add -- file-that-I-changed" to
stage the conflict resolution.

I just updated the topic stage instructions that print when the merge
requested by "git gerrit-merge" has conflicts.  Now they include the
"git submodule update" command just after the "git merge" command, and
an explicit "git add -- files that you changed" line as a reminder.

-Brad