What's (not) cooking

What's (not) cooking

[Junio C Hamano]

I'll be pushing out the integration branches with some updates, but
there is no change in 'next' and below.  The following topics I gave
a quick look and gave them topic branches, but I had trouble merging
them in 'pu' and making them work correctly or pass the tests, so
they are not part of 'pu' in today's pushout.

    pk/rebase-in-c
    en/dirty-merge-fixes
    en/t6036-merge-recursive-tests
    en/t6042-insane-merge-rename-testcases
    ds/multi-pack-index

Re: What's (not) cooking

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> I'll be pushing out the integration branches with some updates, but
> there is no change in 'next' and below.  The following topics I gave
> a quick look and gave them topic branches, but I had trouble merging
> them in 'pu' and making them work correctly or pass the tests, so
> they are not part of 'pu' in today's pushout.
>
>     pk/rebase-in-c
>     en/dirty-merge-fixes
>     en/t6036-merge-recursive-tests
>     en/t6042-insane-merge-rename-testcases
>     ds/multi-pack-index

Also I ran out of time looking at various interesting things that
happened during US holiday, and didn't get around to a few
interesting topics.  So they are not even in the above "not in pu"
list, but they did hit my mailbox.  I just haven't got around to
them yet.

Re: What's (not) cooking

[Elijah Newren]

On Fri, Jul 6, 2018 at 3:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I'll be pushing out the integration branches with some updates, but
> there is no change in 'next' and below.  The following topics I gave
> a quick look and gave them topic branches, but I had trouble merging
> them in 'pu' and making them work correctly or pass the tests, so
> they are not part of 'pu' in today's pushout.
>
>     pk/rebase-in-c
>     en/dirty-merge-fixes
>     en/t6036-merge-recursive-tests
>     en/t6042-insane-merge-rename-testcases
>     ds/multi-pack-index

It looks to me like the main problem is that pu itself has lots of
test failures.  It seems to bisect down to
kg/gc-auto-windows-workaround.  If I revert commit ac9d3fdbebbd ("gc
--auto: clear repository before auto packing", 2018-07-04), then pu
passes tests again for me.  With that reverted, I can merge
en/t6036-merge-recursive-tests and
en/t6042-insane-merge-rename-testcases without conflicts and the tests
pass without incident.

The other three topics all have merge conflicts.

en/dirty-merge-fixes has a small conflict with the new topic
nd/use-the-index-compat-less, which I mentioned as a possibility in
the cover letter to my series.  I'm happy to do whatever makes it
easiest for you to pick up; I can easily rebase on that topic branch,
but I thought you wanted to see that topic redone first (to avoid
"useless churn"), so I'm unsure what the right next step is.

Re: What's (not) cooking

[Johannes Schindelin]

Hi Elijah,

On Fri, 6 Jul 2018, Elijah Newren wrote:

> On Fri, Jul 6, 2018 at 3:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > I'll be pushing out the integration branches with some updates, but
> > there is no change in 'next' and below.  The following topics I gave
> > a quick look and gave them topic branches, but I had trouble merging
> > them in 'pu' and making them work correctly or pass the tests, so
> > they are not part of 'pu' in today's pushout.
> >
> >     pk/rebase-in-c
> >     en/dirty-merge-fixes
> >     en/t6036-merge-recursive-tests
> >     en/t6042-insane-merge-rename-testcases
> >     ds/multi-pack-index
> 
> It looks to me like the main problem is that pu itself has lots of
> test failures.  It seems to bisect down to
> kg/gc-auto-windows-workaround.  If I revert commit ac9d3fdbebbd ("gc
> --auto: clear repository before auto packing", 2018-07-04), then pu
> passes tests again for me.

Is this the segmentation fault about which I just sent a mail?

Ciao,
Dscho

Re: What's (not) cooking

[Elijah Newren]

Hi Dscho,

On Sat, Jul 7, 2018 at 5:11 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Elijah,
>
> On Fri, 6 Jul 2018, Elijah Newren wrote:
>
>> On Fri, Jul 6, 2018 at 3:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> > I'll be pushing out the integration branches with some updates, but
>> > there is no change in 'next' and below.  The following topics I gave
>> > a quick look and gave them topic branches, but I had trouble merging
>> > them in 'pu' and making them work correctly or pass the tests, so
>> > they are not part of 'pu' in today's pushout.
>> >
>> >     pk/rebase-in-c
>> >     en/dirty-merge-fixes
>> >     en/t6036-merge-recursive-tests
>> >     en/t6042-insane-merge-rename-testcases
>> >     ds/multi-pack-index
>>
>> It looks to me like the main problem is that pu itself has lots of
>> test failures.  It seems to bisect down to
>> kg/gc-auto-windows-workaround.  If I revert commit ac9d3fdbebbd ("gc
>> --auto: clear repository before auto packing", 2018-07-04), then pu
>> passes tests again for me.
>
> Is this the segmentation fault about which I just sent a mail?

Yes, this is is a gc segfault issue.  It looks like every test calling
git gc will fail because of it, I even saw a "nothing to pack" message
or something like that followed by a segfault.

Re: What's (not) cooking

[Kim Gybels]

On (07/07/18 08:34), Elijah Newren wrote:
> Hi Dscho,
> 
> On Sat, Jul 7, 2018 at 5:11 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Hi Elijah,
> >
> > On Fri, 6 Jul 2018, Elijah Newren wrote:
> >
> >> On Fri, Jul 6, 2018 at 3:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >> > I'll be pushing out the integration branches with some updates, but
> >> > there is no change in 'next' and below.  The following topics I gave
> >> > a quick look and gave them topic branches, but I had trouble merging
> >> > them in 'pu' and making them work correctly or pass the tests, so
> >> > they are not part of 'pu' in today's pushout.
> >> >
> >> >     pk/rebase-in-c
> >> >     en/dirty-merge-fixes
> >> >     en/t6036-merge-recursive-tests
> >> >     en/t6042-insane-merge-rename-testcases
> >> >     ds/multi-pack-index
> >>
> >> It looks to me like the main problem is that pu itself has lots of
> >> test failures.  It seems to bisect down to
> >> kg/gc-auto-windows-workaround.  If I revert commit ac9d3fdbebbd ("gc
> >> --auto: clear repository before auto packing", 2018-07-04), then pu
> >> passes tests again for me.
> >
> > Is this the segmentation fault about which I just sent a mail?
> 
> Yes, this is is a gc segfault issue.  It looks like every test calling
> git gc will fail because of it, I even saw a "nothing to pack" message
> or something like that followed by a segfault.

Sorry, I forgot to run the tests for v2 of my patch. I'll be more
careful in the future.

-Kim

Re: What's (not) cooking

[Johannes Schindelin]

Hi Junio,

On Fri, 6 Jul 2018, Junio C Hamano wrote:

> I'll be pushing out the integration branches with some updates, but
> there is no change in 'next' and below.  The following topics I gave
> a quick look and gave them topic branches, but I had trouble merging
> them in 'pu' and making them work correctly or pass the tests, so
> they are not part of 'pu' in today's pushout.
> 
>     pk/rebase-in-c
>     en/dirty-merge-fixes
>     en/t6036-merge-recursive-tests
>     en/t6042-insane-merge-rename-testcases
>     ds/multi-pack-index

Quick note that `pu` is broken on Windows:

https://git-for-windows.visualstudio.com/git/git%20Team/_build/results?buildId=11901&view=logs

One quite serious looking symptom is this (line 169728 in the log):

2018-07-07T00:25:33.9171932Z ./test-lib.sh: line 664:  4516 Segmentation
fault      git gc

As you know, some time ago I tried to implement an automated build that
auto-bisects issues like this, and unfortunately I had to disable this
because it regularly ran out of time after 4h to bisect through the
complex commit history (due to the fact that many branches in `pu` are not
based on `master` but on commits that are way back in the past, and an
automated build cannot retain information easily such as "this commit was
clean, and please do not bother bisecting past it".

And sadly, previous tests of `pu` (see
https://git-for-windows.visualstudio.com/git/_build/index?definitionId=1&_a=history)
were failing on Windows already in the compile stage, see
e.g. https://git-for-windows.visualstudio.com/git/git%20Team/_build/results?buildId=11612&view=logs

So I have no idea what caused this `gc` breakage.

Ciao,
Dscho

Re: What's (not) cooking

[Derrick Stolee]

On 7/6/2018 6:57 PM, Junio C Hamano wrote:
> I'll be pushing out the integration branches with some updates, but
> there is no change in 'next' and below.  The following topics I gave
> a quick look and gave them topic branches, but I had trouble merging
> them in 'pu' and making them work correctly or pass the tests, so
> they are not part of 'pu' in today's pushout.
>
>      pk/rebase-in-c
>      en/dirty-merge-fixes
>      en/t6036-merge-recursive-tests
>      en/t6042-insane-merge-rename-testcases
>      ds/multi-pack-index

I tested merging ds/multi-pack-index against the latest pu and the only 
issue I had was with header files being added to 'packfile.c' and 
'building/repack.c'. Both were that I added "#include <midx.h>" and 
cc/remote-odb added "#include <remote-odb.h>".

After resolving those conflicts, I could compile and test as normal. My 
series did not include any new test failures to these that are already 
failing on current pu:

t0410-partial-clone.sh                           (Wstat: 256 Tests: 16 
Failed: 2)
   Failed tests:  15-16
   Non-zero exit status: 1
t1302-repo-version.sh                            (Wstat: 256 Tests: 15 
Failed: 1)
   Failed test:  15
   Non-zero exit status: 1
t1304-default-acl.sh                             (Wstat: 256 Tests: 4 
Failed: 1)
   Failed test:  4
   Non-zero exit status: 1
t3306-notes-prune.sh                             (Wstat: 256 Tests: 12 
Failed: 2)
   Failed tests:  3, 10
   Non-zero exit status: 1
t5304-prune.sh                                   (Wstat: 256 Tests: 26 
Failed: 11)
   Failed tests:  1, 4, 6, 12-18, 20
   Non-zero exit status: 1
t5502-quickfetch.sh                              (Wstat: 256 Tests: 7 
Failed: 1)
   Failed test:  7
   Non-zero exit status: 1
t5318-commit-graph.sh                            (Wstat: 256 Tests: 63 
Failed: 1)
   Failed test:  41
   Non-zero exit status: 1
t5500-fetch-pack.sh                              (Wstat: 256 Tests: 356 
Failed: 1)
   Failed test:  43
   Non-zero exit status: 1
t6014-rev-list-all.sh                            (Wstat: 256 Tests: 4 
Failed: 1)
   Failed test:  3
   Non-zero exit status: 1
t6500-gc.sh                                      (Wstat: 256 Tests: 10 
Failed: 5)
   Failed tests:  2-3, 6-7, 9
   Non-zero exit status: 1
t6501-freshen-objects.sh                         (Wstat: 256 Tests: 29 
Failed: 7)
   Failed tests:  7, 12, 20, 25, 27-29
   Non-zero exit status: 1
t7701-repack-unpack-unreachable.sh               (Wstat: 256 Tests: 7 
Failed: 1)
   Failed test:  5
   Non-zero exit status: 1
t9300-fast-import.sh                             (Wstat: 256 Tests: 183 
Failed: 1)
   Failed test:  88
   Non-zero exit status: 1

Should I rebase onto cc/remote-odb to avoid these conflicts in the 
future? Or, were there more merge conflicts with the other "not cooking" 
branches?

Thanks,
-Stolee

Re: What's (not) cooking

[Junio C Hamano]

Derrick Stolee <stolee@gmail.com> writes:

> On 7/6/2018 6:57 PM, Junio C Hamano wrote:
>> I'll be pushing out the integration branches with some updates, but
>> there is no change in 'next' and below.  The following topics I gave
>> a quick look and gave them topic branches, but I had trouble merging
>> them in 'pu' and making them work correctly or pass the tests, so
>> they are not part of 'pu' in today's pushout.
>>
>>      pk/rebase-in-c
>>      en/dirty-merge-fixes
>>      en/t6036-merge-recursive-tests
>>      en/t6042-insane-merge-rename-testcases
>>      ds/multi-pack-index
>
> I tested merging ds/multi-pack-index against the latest pu and the
> only issue I had was with header files being added to 'packfile.c' and
> 'building/repack.c'. Both were that I added "#include <midx.h>" and
> cc/remote-odb added "#include <remote-odb.h>".

I think ds/multi-pack-index didn't have any difficult textual merge
conflicts.  I ran out of time making 'pu' build with new topics and
listed the ones that were left behind.  As Elijah already
identified, there was a bad apple not listed above that was in 'pu'
that made the tests fail, so the above is not even a complete list
of "bad" topics.  It was merely an "I have them but 'pu' doesn't
include them" list.

Thanks.