diff options
author | Stefan Beller <sbeller@google.com> | 2016-08-09 14:29:13 -0700 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2016-08-09 14:54:16 -0700 |
commit | 2201ee09b542693f3c0c00df9482c098474cb1fe (patch) | |
tree | 0626e8daa7dbbefba6e5c02d90eaee26eb9e7e4d /t/t4101/diff.1-0 | |
parent | submodule-helper: fix indexing in clone retry error reporting path (diff) | |
download | tgif-2201ee09b542693f3c0c00df9482c098474cb1fe.tar.xz |
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>
Diffstat (limited to 't/t4101/diff.1-0')
0 files changed, 0 insertions, 0 deletions