[Insight-developers] Dashboard looks bad today
Gaëtan Lehmann
gaetan.lehmann at jouy.inra.fr
Fri Nov 19 09:27:58 EST 2010
Thanks for the detailed explanation.
Brad L. was definitively right when he said there was no obvious
reason for these test issues ;-)
Gaëtan
Le 19 nov. 10 à 15:03, Brad King a écrit :
> 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
--
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
http://voxel.jouy.inra.fr http://www.itk.org
http://www.mandriva.org http://www.bepo.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20101119/e5944fd8/attachment.pgp>
More information about the Insight-developers
mailing list