1. 27 Dec, 2016 1 commit
  2. 07 Dec, 2016 3 commits
    • 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
      progress.
      
      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: default avatarRobbie Iannucci <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      3f061bf5
    • Junio C Hamano's avatar
      hold_locked_index(): align error handling with hold_lockfile_for_update() · b3e83cc7
      Junio C Hamano authored
      Callers of the hold_locked_index() function pass 0 when they want to
      prepare to write a new version of the index file without wishing to
      die or emit an error message when the request fails (e.g. somebody
      else already held the lock), and pass 1 when they want the call to
      die upon failure.
      
      This option is called LOCK_DIE_ON_ERROR by the underlying lockfile
      API, and the hold_locked_index() function translates the paramter to
      LOCK_DIE_ON_ERROR when calling the hold_lock_file_for_update().
      
      Replace these hardcoded '1' with LOCK_DIE_ON_ERROR and stop
      translating.  Callers other than the ones that are replaced with
      this change pass '0' to the function; no behaviour change is
      intended with this patch.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      ---
      
      Among the callers of hold_locked_index() that passes 0:
      
       - diff.c::refresh_index_quietly() at the end of "git diff" is an
         opportunistic update; it leaks the lockfile structure but it is
         just before the program exits and nobody should care.
      
       - builtin/describe.c::cmd_describe(),
         builtin/commit.c::cmd_status(),
         sequencer.c::read_and_refresh_cache() are all opportunistic
         updates and they are OK.
      
       - builtin/update-index.c::cmd_update_index() takes a lock upfront
         but we may end up not needing to update the index (i.e. the
         entries may be fully up-to-date), in which case we do not need to
         issue an error upon failure to acquire the lock.  We do diagnose
         and die if we indeed need to update, so it is OK.
      
       - wt-status.c::require_clean_work_tree() IS BUGGY.  It asks
         silence, does not check the returned value.  Compare with
         callsites like cmd_describe() and cmd_status() to notice that it
         is wrong to call update_index_if_able() unconditionally.
      b3e83cc7
    • Junio C Hamano's avatar
      wt-status: implement opportunisitc index update correctly · 89d38fb2
      Junio C Hamano authored
      The require_clean_work_tree() function calls hold_locked_index()
      with die_on_error=0 to signal that it is OK if it fails to obtain
      the lock, but unconditionally calls update_index_if_able(), which
      will try to write into fd=-1.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      89d38fb2
  3. 05 Dec, 2016 4 commits
  4. 29 Nov, 2016 25 commits
  5. 28 Nov, 2016 3 commits
  6. 25 Nov, 2016 1 commit
  7. 23 Nov, 2016 3 commits