1. 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: 's avatarJunio C Hamano <gitster@pobox.com>
  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, ...);
      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: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  3. 07 Dec, 2016 1 commit
    • Junio C Hamano's avatar
      lockfile: LOCK_REPORT_ON_ERROR · 3f061bf5
      Junio C Hamano authored
      The "libify sequencer" topic stopped passing the die_on_error option
      to hold_locked_index(), and this lost an error message from "git
      merge --ff-only $commit" when there are competing updates in
      The command still exits with a non-zero status, but that is not of
      much help for an interactive user.  The last thing the command says
      is "Updating $from..$to".  We used to follow it with a big error
      message that makes it clear that "merge --ff-only" did not succeed.
      What is sad is that we should have noticed this regression while
      reviewing the change.  It was clear that the update to the
      checkout_fast_forward() function made a failing hold_locked_index()
      silent, but the only caller of the checkout_fast_forward() function
      had this comment:
      	    if (checkout_fast_forward(from, to, 1))
          -               exit(128); /* the callee should have complained already */
          +               return -1; /* the callee should have complained already */
      which clearly contradicted the assumption X-<.
      Add a new option LOCK_REPORT_ON_ERROR that can be passed instead of
      LOCK_DIE_ON_ERROR to the hold_lock*() family of functions and teach
      checkout_fast_forward() to use it to fix this regression.
      After going thourgh all calls to hold_lock*() family of functions
      that used to pass LOCK_DIE_ON_ERROR but were modified to pass 0 in
      the "libify sequencer" topic "git show --first-parent 2a4062a4",
      it appears that this is the only one that has become silent.  Many
      others used to give detailed report that talked about "there may be
      competing Git process running" but with the series merged they now
      only give a single liner "Unable to lock ...", some of which may
      have to be tweaked further, but at least they say something, unlike
      the one this patch fixes.
      Reported-by: 's avatarRobbie Iannucci <iannucci@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  4. 01 Mar, 2016 2 commits
  5. 28 Aug, 2015 1 commit
  6. 10 Aug, 2015 5 commits
  7. 05 Jun, 2015 3 commits
  8. 19 May, 2015 1 commit
    • Junio C Hamano's avatar
      copy.c: make copy_fd() report its status silently · 00b7cbfc
      Junio C Hamano authored
      When copy_fd() function encounters errors, it emits error messages
      itself, which makes it impossible for callers to take responsibility
      for reporting errors, especially when they want to ignore certain
      Move the error reporting to its callers in preparation.
       - copy_file() and copy_file_with_time() by indirection get their
         own calls to error().
       - hold_lock_file_for_append(), when told to die on error, used to
         exit(128) relying on the error message from copy_fd(), but now it
         does its own die() instead.  Note that the callers that do not
         pass LOCK_DIE_ON_ERROR need to be adjusted for this change, but
         fortunately there is none ;-)
       - filter_buffer_or_fd() has its own error() already, in addition to
         the message from copy_fd(), so this will change the output but
         arguably in a better way.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  9. 14 May, 2015 1 commit
    • Michael Haggerty's avatar
      lockfile: allow file locking to be retried with a timeout · 044b6a9e
      Michael Haggerty authored
      Currently, there is only one attempt to lock a file. If it fails, the
      whole operation fails.
      But it might sometimes be advantageous to try acquiring a file lock a
      few times before giving up. So add a new function,
      hold_lock_file_for_update_timeout(), that allows a timeout to be
      specified. Make hold_lock_file_for_update() a thin wrapper around the
      new function.
      If timeout_ms is positive, then retry for at least that many
      milliseconds to acquire the lock. On each failed attempt, use select()
      to wait for a backoff time that increases quadratically (capped at 1
      second) and has a random component to prevent two processes from
      getting synchronized. If timeout_ms is negative, retry indefinitely.
      In a moment we will switch to using the new function when locking
      Signed-off-by: 's avatarMichael Haggerty <mhagger@alum.mit.edu>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  10. 03 Nov, 2014 1 commit
  11. 15 Oct, 2014 1 commit
  12. 01 Oct, 2014 22 commits