Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Mar 11, 2013
  1. @peff @gitster

    archive: handle commits with an empty tree

    peff authored gitster committed
    git-archive relies on get_pathspec to convert its argv into
    a list of pathspecs. When get_pathspec is given an empty
    argv list, it returns a single pathspec, the empty string,
    to indicate that everything matches. When we feed this to
    our path_exists function, we typically see that the pathspec
    turns up at least one item in the tree, and we are happy.
    
    But when our tree is empty, we erroneously think it is
    because the pathspec is too limited, when in fact it is
    simply that there is nothing to be found in the tree. This
    is a weird corner case, but the correct behavior is almost
    certainly to produce an empty archive, not to exit with an
    error.
    
    This patch teaches git-archive to create empty archives when
    there is no pathspec given (we continue to complain if a
    pathspec is given, since it obviously is not matched). It
    also confirms that the tar and zip writers produce sane
    output in this instance.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Nov 21, 2011
  1. @peff @gitster

    archive: don't let remote clients get unreachable commits

    peff authored gitster committed
    Usually git is careful not to allow clients to fetch
    arbitrary objects from the database; for example, objects
    received via upload-pack must be reachable from a ref.
    Upload-archive breaks this by feeding the client's tree-ish
    directly to get_sha1, which will accept arbitrary hex sha1s,
    reflogs, etc.
    
    This is not a problem if all of your objects are publicly
    reachable anyway (or at least public to anybody who can run
    upload-archive). Or if you are making the repo available by
    dumb protocols like http or rsync (in which case the client
    can read your whole object db directly).
    
    But for sites which allow access only through smart
    protocols, clients may be able to fetch trees from commits
    that exist in the server's object database but are not
    referenced (e.g., because history was rewound).
    
    This patch tightens upload-archive's lookup to use dwim_ref
    rather than get_sha1. This means a remote client can only
    fetch the tip of a named ref, not an arbitrary sha1 or
    reflog entry.
    
    This also restricts some legitimate requests, too:
    
      1. Reachable non-tip commits, like:
    
            git archive --remote=$url v1.0~5
    
      2. Sub-trees of reachable commits, like:
    
            git archive --remote=$url v1.7.7:Documentation
    
    Local requests continue to use get_sha1, and are not
    restricted at all.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jun 22, 2011
  1. @peff @gitster

    upload-archive: allow user to turn off filters

    peff authored gitster committed
    Some tar filters may be very expensive to run, so sites do
    not want to expose them via upload-archive. This patch lets
    users configure tar.<filter>.remote to turn them off.
    
    By default, gzip filters are left on, as they are about as
    expensive as creating zip archives.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @peff @gitster

    archive: refactor file extension format-guessing

    peff authored gitster committed
    Git-archive will guess a format from the output filename if
    no format is explicitly given.  The current function just
    hardcodes "zip" to the zip format, and leaves everything
    else NULL (which will default to tar). Since we are about
    to add user-specified formats, we need to be more flexible.
    The new rule is "if a filename ends with a dot and the name
    of a format, it matches that format". For the existing "tar"
    and "zip" formats, this is identical to the current
    behavior. For new user-specified formats, this will do what
    the user expects if they name their formats appropriately.
    
    Because we will eventually start matching arbitrary
    user-specified extensions that may include dots, the strrchr
    search for the final dot is not sufficient. We need to do an
    actual suffix match with each extension.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. @peff @gitster

    archive: move file extension format-guessing lower

    peff authored gitster committed
    The process for guessing an archive output format based on
    the filename is something like this:
    
      a. parse --output in cmd_archive; check the filename
         against a static set of mapping heuristics (right now
         it just matches ".zip" for zip files).
    
      b. if found, stick a fake "--format=zip" at the beginning
         of the arguments list (if the user did specify a
         --format manually, the later option will override our
         fake one)
    
      c. if it's a remote call, ship the arguments to the remote
         (including the fake), which will call write_archive on
         their end
    
      d. if it's local, ship the arguments to write_archive
         locally
    
    There are two problems:
    
      1. The set of mappings is static and at too high a level.
         The write_archive level is going to check config for
         user-defined formats, some of which will specify
         extensions. We need to delay lookup until those are
         parsed, so we can match against them.
    
      2. For a remote archive call, our set of mappings (or
         formats) may not match the remote side's. This is OK in
         practice right now, because all versions of git
         understand "zip" and "tar". But as new formats are
         added, there is going to be a mismatch between what the
         client can do and what the remote server can do.
    
    To fix (1), this patch refactors the location guessing to
    happen at the write_archive level, instead of the
    cmd_archive level. So instead of sticking a fake --format
    field in the argv list, we actually pass a "name hint" down
    the callchain; this hint is used at the appropriate time to
    guess the format (if one hasn't been given already).
    
    This patch leaves (2) unfixed. The name_hint is converted to
    a "--format" option as before, and passed to the remote.
    This means the local side's idea of how extensions map to
    formats will take precedence.
    
    Another option would be to pass the name hint to the remote
    side and let the remote choose. This isn't a good idea for
    two reasons:
    
      1. There's no room in the protocol for passing that
         information. We can pass a new argument, but older
         versions of git on the server will choke on it.
    
      2. Letting the remote side decide creates a silent
         inconsistency in user experience. Consider the case
         that the locally installed git knows about the "tar.gz"
         format, but a remote server doesn't.
    
         Running "git archive -o foo.tar.gz" will use the tar.gz
         format. If we use --remote, and the local side chooses
         the format, then we send "--format=tar.gz" to the
         remote, which will complain about the unknown format.
         But if we let the remote side choose the format, then
         it will realize that it doesn't know about "tar.gz" and
         output uncompressed tar without even issuing a warning.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  4. @peff @gitster

    archive: pass archiver struct to write_archive callback

    peff authored gitster committed
    The current archivers are very static; when you are in the
    write_tar_archive function, you know you are writing a tar.
    However, to facilitate runtime-configurable archivers
    that will share a common write function we need to tell the
    function which archiver was used.
    
    As a convenience, we also provide an opaque data pointer in
    the archiver struct so that individual archivers can put
    something useful there when they register themselves.
    Technically they could just use the "name" field to look in
    an internal map of names to data, but this is much simpler.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  5. @peff @gitster

    archive: refactor list of archive formats

    peff authored gitster committed
    Most of the tar and zip code was nicely split out into two
    abstracted files which knew only about their specific
    formats. The entry point to this code was a single "write
    archive" function.
    
    However, as these basic formats grow more complex (e.g., by
    handling multiple file extensions and format names), a
    static list of the entry point functions won't be enough.
    Instead, let's provide a way for the tar and zip code to
    tell the main archive code what they support by registering
    archiver names and functions.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jun 15, 2011
  1. @peff @gitster

    archive: reorder option parsing and config reading

    peff authored gitster committed
    The archive command does three things during its
    initialization phase:
    
      1. parse command-line options
    
      2. setup the git directory
    
      3. read config
    
    During phase (1), if we see any options that do not require
    a git directory (like "--list"), we handle them immediately
    and exit, making it safe to abort step (2) if we are not in
    a git directory.
    
    Step (3) must come after step (2), since the git directory
    may influence configuration.  However, this leaves no
    possibility of configuration from step (3) impacting the
    command-line options in step (1) (which is useful, for
    example, for supporting user-configurable output formats).
    
    Instead, let's reorder this to:
    
      1. setup the git directory, if it exists
    
      2. read config
    
      3. parse command-line options
    
      4. if we are not in a git repository, die
    
    This should have the same external behavior, but puts
    configuration before command-line parsing.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Aug 29, 2008
  1. @peff @gitster

    pretty=format: respect date format options

    peff authored gitster committed
    When running a command like:
    
      git log --pretty=format:%ad --date=short
    
    the date option was ignored. This patch causes it to use whatever
    format was specified by --date (or by --relative-date, etc), just
    as the non-user formats would do.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Something went wrong with that request. Please try again.