1. 22 Feb, 2018 2 commits
  2. 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, ...);
        else
                delete_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
           address.
      
        3. Handling a "struct tempfile *" return instead of a file
           descriptor.
      
      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;
                      ...etc
              } *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>
      076aa2cb
  3. 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>
      58311c66
    • 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
      
      or
      
        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>
      a388b10f
    • 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>
      00002396
    • 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>
      fdbdb64f
    • 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>
      56c493ed
  4. 14 Aug, 2017 2 commits
  5. 10 Aug, 2017 1 commit
  6. 25 Jul, 2017 1 commit
  7. 15 Jun, 2017 1 commit
  8. 29 Nov, 2016 4 commits
  9. 21 Oct, 2016 4 commits
  10. 20 Oct, 2016 3 commits
  11. 14 Oct, 2016 1 commit
  12. 12 Oct, 2016 1 commit
  13. 26 Jul, 2016 1 commit
  14. 29 Feb, 2016 1 commit
  15. 14 Jan, 2016 2 commits
  16. 31 Aug, 2015 1 commit
  17. 26 Aug, 2015 1 commit
  18. 21 Aug, 2015 1 commit
    • Christian Couder's avatar
      trailer: ignore first line of message · dc5d553b
      Christian Couder authored
      When looking for the start of the trailers in the message
      we are passed, we should ignore the first line of the message.
      
      The reason is that if we are passed a patch or commit message
      then the first line should be the patch title.
      If we are passed only trailers we can expect that they start
      with an empty line that can be ignored too.
      
      This way we can properly process commit messages that have
      only one line with something that looks like a trailer, for
      example like "area of code: change we made".
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      dc5d553b
  19. 23 Mar, 2015 1 commit
    • Jeff King's avatar
      trailer: use capture_command · c5eadcaa
      Jeff King authored
      When we read from a trailer.*.command sub-program, the
      current code uses run_command followed by a pipe read, which
      can result in deadlock (though in practice you would have to
      have a large trailer for this to be a problem). The current
      code also leaks the file descriptor for the pipe to the
      sub-command.
      
      Instead, let's use capture_command, which makes this simpler
      (and we can get rid of our custom helper).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c5eadcaa
  20. 13 Feb, 2015 1 commit
  21. 10 Nov, 2014 4 commits
  22. 28 Oct, 2014 1 commit