613
So this time will be slightly larger than the atexit time reported by
614
the child process itself.
615
616
+`"child_ready"`::
617
+ This event is generated after the current process has started
618
+ a background process and released all handles to it.
619
++
620
+------------
621
+{
622
+ "event":"child_ready",
623
+ ...
624
+ "child_id":2,
625
+ "pid":14708, # child PID
626
+ "ready":"ready", # child ready state
627
+ "t_rel":0.110605 # observed run-time of child process
628
+}
629
+------------
630
++
631
+Note that the session-id of the child process is not available to
632
+the current/spawning process, so the child's PID is reported here as
633
+a hint for post-processing. (But it is only a hint because the child
634
+process may be a shell script which doesn't have a session-id.)
635
++
636
+This event is generated after the child is started in the background
637
+and given a little time to boot up and start working. If the child
638
+startups normally and while the parent is still waiting, the "ready"
639
+field will have the value "ready".
640
+If the child is too slow to start and the parent times out, the field
641
+will have the value "timeout".
642
+If the child starts but the parent is unable to probe it, the field
643
+will have the value "error".
644
++
645
+After the parent process emits this event, it will release all of its
646
+handles to the child process and treat the child as a background
647
+daemon. So even if the child does eventually finish booting up,
648
+the parent will not emit an updated event.
649
++
650
+Note that the `t_rel` field contains the observed run time in seconds
651
+when the parent released the child process into the background.
652
+The child is assumed to be a long-running daemon process and may
653
+outlive the parent process. So the parent's child event times should
654
+not be compared to the child's atexit times.
655
+
656
`"exec"`::
657
This event is generated before git attempts to `exec()`
658
another command rather than starting a child process.