Re: t3512 & t3513 'unexpected passes'

[Phillip Wood <phillip.wood@talktalk.net>]

On 21/11/17 10:44, Adam Dinwoodie wrote:
> On Monday 20 November 2017 at 08:16 pm +0000, Ramsay Jones wrote:
>> For several days, I have been staring at some 'unexpected passes' in
>> the t3512-cherry-pick-submodule.sh and t3513-revert-submodule.sh test
>> files (tests #11-13 in both cases).

Thanks for pointing this out.

<snip>

> I've seen the same unexpected passes, and had just completed the same
> bisect run myself, although I fixed the build failure by cherry-picking
> 82921316a ("SQUASH???", 2017-11-18) onto commits that wouldn't build,
> given that commit seems to exist entirely to fix that build breakage.  I
> think that adds more weight to b5a812b29 being the culprit for these
> unexpected passes.
> 
> It's definitely the case that these unexpected passes exist at 8e4ff0ae1
> ("Merge branch 'pw/sequencer-in-process-commit' into pu", 2017-11-21)
> and do not exist at its immediate left-hand parent, e017a4ccc ("Merge
> branch 'jn/ssh-wrappers' into jch", 2017-11-21), which means it's
> clearly _something_ in the branch merged at 8e4ff0ae1.

If I've understood the comments by those tests this has to do with the
new code detecting empty commits where the old code does not or vice
versa. The new code detects an attempt to create an empty commit by
comparing the tree that is about to be committed to HEAD and complains
if they are the same. I've had a quick look through the code for 'git
commit' but I need more time to figure out exactly what it does in this
case (I've a feeling from when I looked a while ago that it does this
test before it writes the tree). If anyone has any insight as to why the
tests fail with the current commit implementation that would be helpful
for understanding what is going on here - unfortunately I've never
really used submodules.

Best Wishes

Phillip