Skip to content
Snippets Groups Projects
Select Git revision
6 results Searching

bundle.h

Blame
    • Junio C Hamano's avatar
      c34c9a9d
      bundle v3: the beginning · c34c9a9d
      Junio C Hamano authored
      
      The bundle v3 format introduces an ability to have the bundle header
      (which describes what references in the bundled history can be
      fetched, and what objects the receiving repository must have in
      order to unbundle it successfully) in one file, and the bundled pack
      stream data in a separate file.
      
      A v3 bundle file begins with a line with "# v3 git bundle", followed
      by zero or more "extended header" lines, and an empty line, finally
      followed by the list of prerequisites and references in the same
      format as v2 bundle.  If it uses the "split bundle" feature, there
      is a "data: $URL" extended header line, and nothing follows the list
      of prerequisites and references.  Also, "sha1: " and "size: "
      extended header lines may exist to help validating that the pack
      stream data matches the bundle header.
      
      A typical expected use of a split bundle is to help initial clone
      that involves a huge data transfer, and would go like this:
      
       - Any repository people would clone and fetch from would regularly
         be repacked, and it is expected that there would be a packfile
         without prerequisites that holds all (or at least most) of the
         history of it (call it pack-$name.pack).
      
       - After arranging that packfile to be downloadable over popular
         transfer methods used for serving static files (such as HTTP or
         HTTPS) that are easily resumable as $URL/pack-$name.pack, a v3
         bundle file (call it $name.bndl) can be prepared with an extended
         header "data: $URL/pack-$name.pack" to point at the download
         location for the packfile, and be served at "$URL/$name.bndl".
      
       - An updated Git client, when trying to "git clone" from such a
         repository, may be redirected to $URL/$name.bndl", which would be
         a tiny text file (when split bundle feature is used).
      
       - The client would then inspect the downloaded $name.bndl, learn
         that the corresponding packfile exists at $URL/pack-$name.pack,
         and downloads it as pack-$name.pack, until the download succeeds.
         This can easily be done with "wget --continue" equivalent over an
         unreliable link.  The checksum recorded on the "sha1: " header
         line and the length of the file on the "size: " header line are
         expected to be used by this downloader.
      
       - After fully downloading $name.bndl and pack-$name.pack and
         storing them next to each other, the client would clone from the
         $name.bndl; this would populate the newly created repository with
         reasonably recent history.
      
       - Then the client can issue "git fetch" against the original
         repository to obtain the most recent part of the history created
         since the bundle was made.
      
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c34c9a9d
      History
      bundle v3: the beginning
      Junio C Hamano authored
      
      The bundle v3 format introduces an ability to have the bundle header
      (which describes what references in the bundled history can be
      fetched, and what objects the receiving repository must have in
      order to unbundle it successfully) in one file, and the bundled pack
      stream data in a separate file.
      
      A v3 bundle file begins with a line with "# v3 git bundle", followed
      by zero or more "extended header" lines, and an empty line, finally
      followed by the list of prerequisites and references in the same
      format as v2 bundle.  If it uses the "split bundle" feature, there
      is a "data: $URL" extended header line, and nothing follows the list
      of prerequisites and references.  Also, "sha1: " and "size: "
      extended header lines may exist to help validating that the pack
      stream data matches the bundle header.
      
      A typical expected use of a split bundle is to help initial clone
      that involves a huge data transfer, and would go like this:
      
       - Any repository people would clone and fetch from would regularly
         be repacked, and it is expected that there would be a packfile
         without prerequisites that holds all (or at least most) of the
         history of it (call it pack-$name.pack).
      
       - After arranging that packfile to be downloadable over popular
         transfer methods used for serving static files (such as HTTP or
         HTTPS) that are easily resumable as $URL/pack-$name.pack, a v3
         bundle file (call it $name.bndl) can be prepared with an extended
         header "data: $URL/pack-$name.pack" to point at the download
         location for the packfile, and be served at "$URL/$name.bndl".
      
       - An updated Git client, when trying to "git clone" from such a
         repository, may be redirected to $URL/$name.bndl", which would be
         a tiny text file (when split bundle feature is used).
      
       - The client would then inspect the downloaded $name.bndl, learn
         that the corresponding packfile exists at $URL/pack-$name.pack,
         and downloads it as pack-$name.pack, until the download succeeds.
         This can easily be done with "wget --continue" equivalent over an
         unreliable link.  The checksum recorded on the "sha1: " header
         line and the length of the file on the "size: " header line are
         expected to be used by this downloader.
      
       - After fully downloading $name.bndl and pack-$name.pack and
         storing them next to each other, the client would clone from the
         $name.bndl; this would populate the newly created repository with
         reasonably recent history.
      
       - Then the client can issue "git fetch" against the original
         repository to obtain the most recent part of the history created
         since the bundle was made.
      
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    ctype.c 890 B