Is this a threading bug?

Is this a threading bug?

[Leo]

I am running Gnus (emacs-trunk).

Viewing the thread started at Message-ID:
<1305960995-25738-1-git-send-email-gitster@pobox.com> on gmane.comp.version-control.git

Before:

R.  │21-May│ Junio C Hamano  │4.5k│  │┌ [PATCH v3 00/12] writing out a huge blob to working tree
 .  │21-May│ Junio C Hamano  │5.7k│  │├─► [PATCH v3 01/12] packed_object_info_detail(): do not return a string
 .  │21-May│ Junio C Hamano  │8.6k│  │├─► [PATCH v3 02/12] sha1_object_info_extended(): expose a bit more info
 .  │21-May│ Junio C Hamano  │4.8k│  │├─► [PATCH v3 03/12] sha1_object_info_extended(): hint about objects in delta-base cache
 .  │21-May│ Junio C Hamano  │4.6k│  │├─► [PATCH v3 04/12] unpack_object_header(): make it public
 .  │21-May│ Junio C Hamano  │5.7k│  │├─► [PATCH v3 05/12] write_entry(): separate two helper functions out
 .  │21-May│ Junio C Hamano  │9.4k│  │├─► [PATCH v3 06/12] streaming: a new API to read from the object store
 .  │21-May│ Junio C Hamano  │8.0k│  │├─► [PATCH v3 07/12] streaming_write_entry(): use streaming API in write_entry()
 .  │21-May│ Junio C Hamano  │4.7k│  │├─► [PATCH v3 09/12] streaming_write_entry(): support files with holes
 .  │21-May│ Junio C Hamano  │3.7k│  │├─► [PATCH v3 08/12] convert: CRLF_INPUT is a no-op in the output codepath
 .  │21-May│ Junio C Hamano  │6.5k│  │├─► [PATCH v3 10/12] streaming: read non-delta incrementally from a pack
 .  │21-May│ Junio C Hamano  │5.5k│  │├─► [PATCH v3 11/12] sha1_file.c: expose helpers to read loose objects
 .  │21-May│ Junio C Hamano  │5.8k│  │└─► [PATCH v3 12/12] streaming: read loose objects incrementally

After removing the read article "[PATCH v3 00/12] writing out a huge
blob to working tree" the thread looks like:

 .  │21-May│ Junio C Hamano  │5.7k│  │◯ [PATCH v3 01/12] packed_object_info_detail(): do not return a string
 .  │21-May│ Junio C Hamano  │8.6k│  │  └─► [PATCH v3 02/12] sha1_object_info_extended(): expose a bit more info
 .  │21-May│ Junio C Hamano  │4.8k│  │    └─► [PATCH v3 03/12] sha1_object_info_extended(): hint about objects in delta-base cache
 .  │21-May│ Junio C Hamano  │4.6k│  │      └─► [PATCH v3 04/12] unpack_object_header(): make it public
 .  │21-May│ Junio C Hamano  │5.7k│  │        └─► [PATCH v3 05/12] write_entry(): separate two helper functions out
 .  │21-May│ Junio C Hamano  │9.4k│  │          └─► [PATCH v3 06/12] streaming: a new API to read from the object store
 .  │21-May│ Junio C Hamano  │8.0k│  │            └─► [PATCH v3 07/12] streaming_write_entry(): use streaming API in write_entry()
 .  │21-May│ Junio C Hamano  │4.7k│  │              └─► [PATCH v3 09/12] streaming_write_entry(): support files with holes
 .  │21-May│ Junio C Hamano  │3.7k│  │                └─► [PATCH v3 08/12] convert: CRLF_INPUT is a no-op in the output codepath
 .  │21-May│ Junio C Hamano  │6.5k│  │                  └─► [PATCH v3 10/12] streaming: read non-delta incrementally from a pack
 .  │21-May│ Junio C Hamano  │5.5k│  │                    └─► [PATCH v3 11/12] sha1_file.c: expose helpers to read loose objects
 .  │21-May│ Junio C Hamano  │5.8k│  │                      └─► [PATCH v3 12/12] streaming: read loose objects incrementally


Does anyone else see this and is it a bug? Thanks.

Leo

Re: Is this a threading bug?

[Lars Magne Ingebrigtsen]

Leo <sdl.web@gmail.com> writes:

> After removing the read article "[PATCH v3 00/12] writing out a huge
> blob to working tree" the thread looks like:

It certainly looks odd, but it might be the result of gathering false
threads after removing a threading loop, and then doing the threading
for real when the loop is removed?  Or something?  I'm just guessing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/