submodule--helper: use parallel processor correctly
commit2201ee09b542693f3c0c00df9482c098474cb1fe
authorStefan Beller <sbeller@google.com>
Tue, 9 Aug 2016 21:29:13 +0000 (9 14:29 -0700)
committerJunio C Hamano <gitster@pobox.com>
Tue, 9 Aug 2016 21:54:16 +0000 (9 14:54 -0700)
tree0626e8daa7dbbefba6e5c02d90eaee26eb9e7e4d
parenteb09121b745e9aa5bbd3fa438f873c3511f48b33
submodule--helper: use parallel processor correctly

When developing another patch series I had a temporary state in
which git-clone would segfault, when the call was prepared in
prepare_to_clone_next_submodule. This lead to the call failing,
i.e. in `update_clone_task_finished` the task was scheduled to be
tried again.  The second call to prepare_to_clone_next_submodule
would return 0, as the segfaulted clone did create the .git file
already, such that was not considered to need to be cloned again. I
was seeing the "BUG: ce was a submodule before?\n" message, which
was the correct behavior at the time as my local code was
buggy. When trying to debug this failure, I tried to use printing
messages into the strbuf that is passed around, but these messages
were never printed as the die(..) doesn't flush the `err` strbuf.

When implementing the die() in 665b35ecc (2016-06-09, "submodule--helper:
initial clone learns retry logic"), I considered this condition to be
a severe condition, which should lead to an immediate abort as we do not
trust ourselves any more. However the queued messages in `err` are valuable
so let's not toss them out by immediately dying, but a graceful return.

Another thing to note: The error message itself was misleading. A return
value of 0 doesn't indicate the passed in `ce` is not a submodule any more,
but just that we do not consider cloning it any more.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/submodule--helper.c