@@ -425,8 +425,8 @@ packet: git< capability=clean
425
425
packet: git< capability=smudge
426
426
packet: git< 0000
427
427
------------------------
428
- Supported filter capabilities in version 2 are "clean" and
429
- "smudge ".
428
+ Supported filter capabilities in version 2 are "clean", "smudge",
429
+ and "delay ".
430
430
431
431
Afterwards Git sends a list of "key=value" pairs terminated with
432
432
a flush packet. The list will contain at least the filter command
@@ -512,12 +512,69 @@ the protocol then Git will stop the filter process and restart it
512
512
with the next file that needs to be processed. Depending on the
513
513
`filter.<driver>.required` flag Git will interpret that as error.
514
514
515
- After the filter has processed a blob it is expected to wait for
516
- the next "key=value" list containing a command. Git will close
515
+ After the filter has processed a command it is expected to wait for
516
+ a "key=value" list containing the next command. Git will close
517
517
the command pipe on exit. The filter is expected to detect EOF
518
518
and exit gracefully on its own. Git will wait until the filter
519
519
process has stopped.
520
520
521
+ Delay
522
+ ^^^^^
523
+
524
+ If the filter supports the "delay" capability, then Git can send the
525
+ flag "can-delay" after the filter command and pathname. This flag
526
+ denotes that the filter can delay filtering the current blob (e.g. to
527
+ compensate network latencies) by responding with no content but with
528
+ the status "delayed" and a flush packet.
529
+ ------------------------
530
+ packet: git> command=smudge
531
+ packet: git> pathname=path/testfile.dat
532
+ packet: git> can-delay=1
533
+ packet: git> 0000
534
+ packet: git> CONTENT
535
+ packet: git> 0000
536
+ packet: git< status=delayed
537
+ packet: git< 0000
538
+ ------------------------
539
+
540
+ If the filter supports the "delay" capability then it must support the
541
+ "list_available_blobs" command. If Git sends this command, then the
542
+ filter is expected to return a list of pathnames of blobs that are
543
+ available. The list must be terminated with a flush packet followed
544
+ by a "success" status that is also terminated with a flush packet. If
545
+ no blobs for the delayed paths are available, yet, then the filter is
546
+ expected to block the response until at least one blob becomes
547
+ available. The filter can tell Git that it has no more delayed blobs
548
+ by sending an empty list.
549
+ ------------------------
550
+ packet: git> command=list_available_blobs
551
+ packet: git> 0000
552
+ packet: git< pathname=path/testfile.dat
553
+ packet: git< pathname=path/otherfile.dat
554
+ packet: git< 0000
555
+ packet: git< status=success
556
+ packet: git< 0000
557
+ ------------------------
558
+
559
+ After Git received the pathnames, it will request the corresponding
560
+ blobs again. These requests contain a pathname and an empty content
561
+ section. The filter is expected to respond with the smudged content
562
+ in the usual way as explained above.
563
+ ------------------------
564
+ packet: git> command=smudge
565
+ packet: git> pathname=path/testfile.dat
566
+ packet: git> 0000
567
+ packet: git> 0000 # empty content!
568
+ packet: git< status=success
569
+ packet: git< 0000
570
+ packet: git< SMUDGED_CONTENT
571
+ packet: git< 0000
572
+ packet: git< 0000 # empty list, keep "status=success" unchanged!
573
+ ------------------------
574
+
575
+ Example
576
+ ^^^^^^^
577
+
521
578
A long running filter demo implementation can be found in
522
579
`contrib/long-running-filter/example.pl` located in the Git
523
580
core repository. If you develop your own long running filter
0 commit comments