1. 22 Feb, 2016 1 commit
  2. 20 Nov, 2015 2 commits
  3. 05 Oct, 2015 1 commit
    • Jeff King's avatar
      avoid sprintf and strcpy with flex arrays · c7ab0ba3
      Jeff King authored
      When we are allocating a struct with a FLEX_ARRAY member, we
      generally compute the size of the array and then sprintf or
      strcpy into it. Normally we could improve a dynamic allocation
      like this by using xstrfmt, but it doesn't work here; we
      have to account for the size of the rest of the struct.
      
      But we can improve things a bit by storing the length that
      we use for the allocation, and then feeding it to xsnprintf
      or memcpy, which makes it more obvious that we are not
      writing more than the allocated number of bytes.
      
      It would be nice if we had some kind of helper for
      allocating generic flex arrays, but it doesn't work that
      well:
      
       - the call signature is a little bit unwieldy:
      
            d = flex_struct(sizeof(*d), offsetof(d, path), fmt, ...);
      
         You need offsetof here instead of just writing to the
         end of the base size, because we don't know how the
         struct is packed (partially this is because FLEX_ARRAY
         might not be zero, though we can account for that; but
         the size of the struct may actually be rounded up for
         alignment, and we can't know that).
      
       - some sites do clever things, like over-allocating because
         they know they will write larger things into the buffer
         later (e.g., struct packed_git here).
      
      So we're better off to just write out each allocation (or
      add type-specific helpers, though many of these are one-off
      allocations anyway).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c7ab0ba3
  4. 29 Jun, 2015 1 commit
    • Jeff King's avatar
      convert "enum date_mode" into a struct · a5481a6c
      Jeff King authored
      In preparation for adding date modes that may carry extra
      information beyond the mode itself, this patch converts the
      date_mode enum into a struct.
      
      Most of the conversion is fairly straightforward; we pass
      the struct as a pointer and dereference the type field where
      necessary. Locations that declare a date_mode can use a "{}"
      constructor.  However, the tricky case is where we use the
      enum labels as constants, like:
      
        show_date(t, tz, DATE_NORMAL);
      
      Ideally we could say:
      
        show_date(t, tz, &{ DATE_NORMAL });
      
      but of course C does not allow that. Likewise, we cannot
      cast the constant to a struct, because we need to pass an
      actual address. Our options are basically:
      
        1. Manually add a "struct date_mode d = { DATE_NORMAL }"
           definition to each caller, and pass "&d". This makes
           the callers uglier, because they sometimes do not even
           have their own scope (e.g., they are inside a switch
           statement).
      
        2. Provide a pre-made global "date_normal" struct that can
           be passed by address. We'd also need "date_rfc2822",
           "date_iso8601", and so forth. But at least the ugliness
           is defined in one place.
      
        3. Provide a wrapper that generates the correct struct on
           the fly. The big downside is that we end up pointing to
           a single global, which makes our wrapper non-reentrant.
           But show_date is already not reentrant, so it does not
           matter.
      
      This patch implements 3, along with a minor macro to keep
      the size of the callers sane.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a5481a6c
  5. 22 Jun, 2015 1 commit
  6. 14 Mar, 2015 1 commit
  7. 14 Jan, 2015 1 commit
  8. 01 Dec, 2014 1 commit
  9. 22 Sep, 2014 1 commit
    • Duy Nguyen's avatar
      archive: support filtering paths with glob · ed22b417
      Duy Nguyen authored
      This patch fixes two problems with using :(glob) (or even "*.c"
      without ":(glob)").
      
      The first one is we forgot to turn on the 'recursive' flag in struct
      pathspec. Without that, tree_entry_interesting() will not mark
      potential directories "interesting" so that it can confirm whether
      those directories have anything matching the pathspec.
      
      The marking directories interesting has a side effect that we need to
      walk inside a directory to realize that there's nothing interested in
      there. By that time, 'archive' code has already written the (empty)
      directory down. That means lots of empty directories in the result
      archive.
      
      This problem is fixed by lazily writing directories down when we know
      they are actually needed. There is a theoretical bug in this
      implementation: we can't write empty trees/directories that match that
      pathspec.
      
      path_exists() is also made stricter in order to detect non-matching
      pathspec because when this 'recursive' flag is on, we most likely
      match some directories. The easiest way is not consider any
      directories "matched".
      Noticed-by: Peter Wu's avatarPeter Wu <peter@lekensteyn.nl>
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ed22b417
  10. 07 Aug, 2014 1 commit
  11. 10 Mar, 2014 1 commit
  12. 28 Feb, 2014 1 commit
    • Scott J. Goldman's avatar
      add uploadarchive.allowUnreachable option · 7671b632
      Scott J. Goldman authored
      In commit ee27ca4a, we started restricting remote git-archive
      invocations to only accessing reachable commits. This
      matches what upload-pack allows, but does restrict some
      useful cases (e.g., HEAD:foo). We loosened this in 0f544ee8,
      which allows `foo:bar` as long as `foo` is a ref tip.
      However, that still doesn't allow many useful things, like:
      
        1. Commits accessible from a ref, like `foo^:bar`, which
           are reachable
      
        2. Arbitrary sha1s, even if they are reachable.
      
      We can do a full object-reachability check for these cases,
      but it can be quite expensive if the client has sent us the
      sha1 of a tree; we have to visit every sub-tree of every
      commit in the worst case.
      
      Let's instead give site admins an escape hatch, in case they
      prefer the more liberal behavior.  For many sites, the full
      object database is public anyway (e.g., if you allow dumb
      walker access), or the site admin may simply decide the
      security/convenience tradeoff is not worth it.
      
      This patch adds a new config option to disable the
      restrictions added in ee27ca4a. It defaults to off, meaning
      there is no change in behavior by default.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      7671b632
  13. 16 Oct, 2013 1 commit
  14. 15 Jul, 2013 2 commits
  15. 11 Mar, 2013 1 commit
    • Jeff King's avatar
      archive: handle commits with an empty tree · bd54cf17
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      bd54cf17
  16. 18 Dec, 2012 1 commit
  17. 22 Aug, 2012 1 commit
  18. 20 Aug, 2012 1 commit
  19. 18 May, 2012 1 commit
  20. 03 May, 2012 1 commit
  21. 12 Jan, 2012 1 commit
  22. 21 Nov, 2011 1 commit
    • Jeff King's avatar
      archive: don't let remote clients get unreachable commits · ee27ca4a
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ee27ca4a
  23. 28 Sep, 2011 1 commit
    • Junio C Hamano's avatar
      archive.c: use OPT_BOOL() · f858c646
      Junio C Hamano authored
      The list variable (which is OPT_BOOLEAN) is initialized to 0 and only
      checked against 0 in the code, so it is safe to use OPT_BOOL().
      
      The worktree_attributes variable (which is OPT_BOOLEAN) is initialized to
      0 and later assigned to a field with the same name in struct archive_args,
      which is a bitfield of width 1. It is safe and even more correct to use
      OPT_BOOL() here; the new test in 5001 demonstrates why using OPT_COUNTUP
      is wrong.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      f858c646
  24. 04 Aug, 2011 1 commit
  25. 22 Jun, 2011 5 commits
    • Jeff King's avatar
      upload-archive: allow user to turn off filters · 7b97730b
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      7b97730b
    • Jeff King's avatar
      archive: refactor file extension format-guessing · 08716b3c
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      08716b3c
    • Jeff King's avatar
      archive: move file extension format-guessing lower · 56baa61d
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      56baa61d
    • Jeff King's avatar
      archive: pass archiver struct to write_archive callback · 4d7c9898
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4d7c9898
    • Jeff King's avatar
      archive: refactor list of archive formats · 13e0f88d
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      13e0f88d
  26. 15 Jun, 2011 1 commit
    • Jeff King's avatar
      archive: reorder option parsing and config reading · 23212862
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      23212862
  27. 25 Mar, 2011 1 commit
  28. 15 Nov, 2010 2 commits
  29. 08 Oct, 2010 1 commit
  30. 27 Jul, 2010 1 commit
  31. 17 Jan, 2010 1 commit
  32. 30 Dec, 2009 1 commit
  33. 20 Oct, 2009 1 commit
    • Thomas Rast's avatar
      Refactor pretty_print_commit arguments into a struct · dd2e794a
      Thomas Rast authored
      pretty_print_commit() has a bunch of rarely-used arguments, and
      introducing more of them requires yet another update of all the call
      sites.  Refactor most of them into a struct to make future extensions
      easier.
      
      The ones that stay "plain" arguments were chosen on the grounds that
      all callers put real arguments there, whereas some callers have 0/NULL
      for all arguments that were factored into the struct.
      
      We declare the struct 'const' to ensure none of the callers are bitten
      by the changed (no longer call-by-value) semantics.
      Signed-off-by: default avatarThomas Rast <trast@student.ethz.ch>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      dd2e794a