1. 29 Jan, 2019 3 commits
  2. 23 Aug, 2018 5 commits
    • Jeff King's avatar
      interpret-trailers: allow suppressing "---" divider · 1688c9a4
      Jeff King authored
      Even with the newly-tightened "---" parser, it's still
      possible for a commit message to trigger a false positive if
      it contains something like "--- foo". If the caller knows
      that it has only a single commit message, it can now tell us
      with the "--no-divider" option, eliminating any false
      If we were designing this from scratch, I'd probably make
      this the default. But we've advertised the "---" behavior in
      the documentation since interpret-trailers has existed.
      Since it's meant to be scripted, breaking that would be a
      bad idea.
      Note that the logic is in the underlying trailer.c code,
      which is used elsewhere. The default there will keep the
      current behavior, but many callers will benefit from setting
      this new option. That's left for future patches.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      interpret-trailers: tighten check for "---" patch boundary · c188668e
      Jeff King authored
      The interpret-trailers command accepts not only raw commit
      messages, but it also can manipulate trailers in
      format-patch output. That means it must find the "---"
      boundary separating the commit message from the patch.
      However, it does so by looking for any line starting with
      "---", regardless of whether there is further content.
      This is overly lax compared to the parsing done in
      mailinfo.c's patchbreak(), and may cause false positives
      (e.g., t/perf output tables uses dashes; if you cut and
      paste them into your commit message, it fools the parser).
      We could try to reuse patchbreak() here, but it actually has
      several heuristics that are not of interest to us (e.g.,
      matching "diff -" without a three-dash separator or even a
      CVS "Index:" line). We're not interested in taking in
      whatever random cruft people may send, but rather handling
      git-formatted patches.
      Note that the existing documentation was written in a loose
      way, so technically we are changing the behavior from what
      it said. But this should implement the original intent in a
      more accurate way.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      trailer: pass process_trailer_opts to trailer_info_get() · 00a21f5c
      Jeff King authored
      Most of the trailer code has an "opts" struct which is
      filled in by the caller. We don't pass it down to
      trailer_info_get(), which does the initial parsing, because
      there hasn't yet been a need to do so.
      Let's start passing it down in preparation for adding new
      options. Note that there's a single caller which doesn't
      otherwise have such an options struct. Since it's just one
      caller (that we'd have to modify anyway), let's not bother
      with any special treatment like accepting a NULL options
      struct, and just have it allocate one with the defaults.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      trailer: use size_t for iterating trailer list · a3b636e2
      Jeff King authored
      We store the length of the trailers list in a size_t. So on
      a 64-bit system with a 32-bit int, in the unlikely case that
      we manage to actually allocate a list with 2^31 entries,
      we'd loop forever trying to iterate over it (our "int" would
      wrap to negative before exceeding info->trailer_nr).
      This probably doesn't matter in practice. Each entry is at
      least a pointer plus a non-empty string, so even without
      malloc overhead or the memory to hold the original string
      we're parsing from, you'd need to allocate tens of
      gigabytes. But it's easy enough to do it right.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      trailer: use size_t for string offsets · 0d2db00e
      Jeff King authored
      Many of the string-parsing functions inside trailer.c return
      integer offsets into the string (e.g., to point to the end
      of the trailer block). Several of these use an "int" to
      return or store the offsets. On a system where "size_t" is
      much larger than "int" (e.g., most 64-bit ones), it's easy
      to feed a gigantic commit message that results in a negative
      offset. This can result in us reading memory before the
      string (if the int is used as an index) or far after (if
      it's implicitly cast to a size_t by passing to a strbuf
      Let's fix this by using size_t for all string offsets. Note
      that several of the functions need ssize_t, since they use
      "-1" as a sentinel value. The interactions here can be
      pretty subtle. E.g., end_of_title in find_trailer_start()
      does not itself need to be signed, but it is compared to the
      result of last_line(), which is. That promotes the latter to
      unsigned, and the ">=" does not behave as you might expect.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  3. 06 May, 2018 1 commit
    • Johannes Schindelin's avatar
      Replace all die("BUG: ...") calls by BUG() ones · 033abf97
      Johannes Schindelin authored
      In d8193743 (usage.c: add BUG() function, 2017-05-12), a new macro
      was introduced to use for reporting bugs instead of die(). It was then
      subsequently used to convert one single caller in 588a538a
      (setup_git_env: convert die("BUG") to BUG(), 2017-05-12).
      The cover letter of the patch series containing this patch
      (cf 20170513032414.mfrwabt4hovujde2@sigill.intra.peff.net) is not
      terribly clear why only one call site was converted, or what the plan
      is for other, similar calls to die() to report bugs.
      Let's just convert all remaining ones in one fell swoop.
      This trick was performed by this invocation:
      	sed -i 's/die("BUG: /BUG("/g' $(git grep -l 'die("BUG' \*.c)
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  4. 22 Feb, 2018 2 commits
  5. 06 Sep, 2017 1 commit
    • Jeff King's avatar
      tempfile: auto-allocate tempfiles on heap · 076aa2cb
      Jeff King authored
      The previous commit taught the tempfile code to give up
      ownership over tempfiles that have been renamed or deleted.
      That makes it possible to use a stack variable like this:
        struct tempfile t;
        create_tempfile(&t, ...);
        if (!err)
                rename_tempfile(&t, ...);
      But doing it this way has a high potential for creating
      memory errors. The tempfile we pass to create_tempfile()
      ends up on a global linked list, and it's not safe for it to
      go out of scope until we've called one of those two
      deactivation functions.
      Imagine that we add an early return from the function that
      forgets to call delete_tempfile(). With a static or heap
      tempfile variable, the worst case is that the tempfile hangs
      around until the program exits (and some functions like
      setup_shallow_temporary rely on this intentionally, creating
      a tempfile and then leaving it for later cleanup).
      But with a stack variable as above, this is a serious memory
      error: the variable goes out of scope and may be filled with
      garbage by the time the tempfile code looks at it.  Let's
      see if we can make it harder to get this wrong.
      Since many callers need to allocate arbitrary numbers of
      tempfiles, we can't rely on static storage as a general
      solution. So we need to turn to the heap. We could just ask
      all callers to pass us a heap variable, but that puts the
      burden on them to call free() at the right time.
      Instead, let's have the tempfile code handle the heap
      allocation _and_ the deallocation (when the tempfile is
      deactivated and removed from the list).
      This changes the return value of all of the creation
      functions. For the cleanup functions (delete and rename),
      we'll add one extra bit of safety: instead of taking a
      tempfile pointer, we'll take a pointer-to-pointer and set it
      to NULL after freeing the object. This makes it safe to
      double-call functions like delete_tempfile(), as the second
      call treats the NULL input as a noop. Several callsites
      follow this pattern.
      The resulting patch does have a fair bit of noise, as each
      caller needs to be converted to handle:
        1. Storing a pointer instead of the struct itself.
        2. Passing the pointer instead of taking the struct
        3. Handling a "struct tempfile *" return instead of a file
      We could play games to make this less noisy. For example, by
      defining the tempfile like this:
        struct tempfile {
      	struct heap_allocated_part_of_tempfile {
                      int fd;
              } *actual_data;
      Callers would continue to have a "struct tempfile", and it
      would be "active" only when the inner pointer was non-NULL.
      But that just makes things more awkward in the long run.
      There aren't that many callers, so we can simply bite
      the bullet and adjust all of them. And the compiler makes it
      easy for us to find them all.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  6. 15 Aug, 2017 5 commits
    • Jeff King's avatar
      pretty: support normalization options for %(trailers) · 58311c66
      Jeff King authored
      The interpret-trailers command recently learned some options
      to make its output easier to parse (for a caller whose only
      interested in picking out the trailer values). But it's not
      very efficient for asking for the trailers of many commits
      in a single invocation.
      We already have "%(trailers)" to do that, but it doesn't
      know about unfolding or omitting non-trailers. Let's plumb
      those options through, so you can have the best of both.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      pretty: move trailer formatting to trailer.c · a388b10f
      Jeff King authored
      The next commit will add many features to the %(trailer)
      placeholder in pretty.c. We'll need to access some internal
      functions of trailer.c for that, so our options are either:
        1. expose those functions publicly
        2. make an entry point into trailer.c to do the formatting
      Doing (2) ends up exposing less surface area, though do note
      that caveats in the docstring of the new function.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      interpret-trailers: add an option to unfold values · 00002396
      Jeff King authored
      The point of "--only-trailers" is to give a caller an output
      that's easy for them to parse. Getting rid of the
      non-trailer material helps, but we still may see more
      complicated syntax like whitespace continuation. Let's add
      an option to unfold any continuation, giving the output as a
      single "key: value" line per trailer.
      As a bonus, this could be used even without --only-trailers
      to clean up unusual formatting in the incoming data.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      interpret-trailers: add an option to show only existing trailers · fdbdb64f
      Jeff King authored
      It can be useful to invoke interpret-trailers for the
      primary purpose of parsing existing trailers. But in that
      case, we don't want to apply existing ifMissing or ifExists
      rules from the config. Let's add a special mode where we
      avoid applying those rules. Coupled with --only-trailers,
      this gives us a reasonable parsing tool.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      interpret-trailers: add an option to show only the trailers · 56c493ed
      Jeff King authored
      In theory it's easy for any reader who wants to parse
      trailers to do so. But there are a lot of subtle corner
      cases around what counts as a trailer, when the trailer
      block begins and ends, etc. Since interpret-trailers already
      has our parsing logic, let's let callers ask it to just
      output the trailers.
      They still have to parse the "key: value" lines, but at
      least they can ignore all of the other corner cases.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  7. 14 Aug, 2017 2 commits
  8. 10 Aug, 2017 1 commit
  9. 25 Jul, 2017 1 commit
  10. 15 Jun, 2017 1 commit
  11. 29 Nov, 2016 4 commits
  12. 21 Oct, 2016 4 commits
  13. 20 Oct, 2016 3 commits
  14. 14 Oct, 2016 1 commit
  15. 12 Oct, 2016 1 commit
  16. 26 Jul, 2016 1 commit
  17. 29 Feb, 2016 1 commit
  18. 14 Jan, 2016 2 commits
  19. 31 Aug, 2015 1 commit