1. 27 3月, 2013 11 次提交
  2. 26 3月, 2013 11 次提交
  3. 22 3月, 2013 7 次提交
    • M
      diff.c: diff.renamelimit => diff.renameLimit in message · c9fc4415
      Max Nanasy 提交于
      In the warning message printed when rename or unmodified copy
      detection was skipped due to too many files, change "diff.renamelimit"
      to "diff.renameLimit", in order to make it consistent with git
      documentation, which consistently uses "diff.renameLimit".
      Signed-off-by: NMax Nanasy <max.nanasy@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c9fc4415
    • J
      wt-status: fix possible use of uninitialized variable · b8527d5f
      Jeff King 提交于
      In wt_status_print_change_data, we accept a change_type flag
      that is meant to be either WT_STATUS_UPDATED or
      WT_STATUS_CHANGED.  We then switch() on this value to set
      the local variable "status" for each case, but do not
      provide a fallback "default" label to the switch statement.
      
      As a result, the compiler realizes that "status" might be
      unset, and complains with a warning. To silence this
      warning, we use the "int status = status" trick.  This is
      correct with the current code, as all callers provide one of
      the two expected change_type flags. However, it's also a
      maintenance trap, as there is nothing to prevent future
      callers from passing another flag, nor to document this
      assumption.
      
      Instead of using the "x = x" hack, let's handle the default
      case in the switch() statement with a die("BUG"). That tells
      the compiler and any readers of the code exactly what the
      function's input assumptions are.
      
      We could also convert the flag to an enum, which would
      provide a compile-time check on the function input. However,
      since these flags are part of a larger enum, that would make
      the code unnecessarily complex (we would have to make a new
      enum with just the two flags, and then convert it to the old
      enum for passing to sub-functions).
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b8527d5f
    • J
      fast-import: clarify "inline" logic in file_change_m · 3aa99df8
      Jeff King 提交于
      When we read a fast-import line like:
      
        M 100644 :1 foo.c
      
      we point the local object_entry variable "oe" to the object
      named by the mark ":1". When the input uses the "inline"
      construct, however, we do not have such an object_entry.
      
      The current code is careful not to access "oe" in the inline
      case, but we can make the assumption even more obvious (and
      catch violations of it) by setting oe to NULL and adding a
      comment. As a bonus, this also squelches an over-zealous gcc
      -Wuninitialized warning, which means we can drop the "oe =
      oe" initialization hack.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3aa99df8
    • J
      run-command: always set failed_errno in start_command · 25043d8a
      Jeff King 提交于
      When we fail to fork, we set the failed_errno variable to
      the value of errno so it is not clobbered by later syscalls.
      However, we do so in a conditional, and it is hard to see
      later under what conditions the variable has a valid value.
      
      Instead of setting it only when fork fails, let's just
      always set it after forking. This is more obvious for human
      readers (as we are no longer setting it as a side effect of
      a strerror call), and it is more obvious to gcc, which no
      longer generates a spurious -Wuninitialized warning. It also
      happens to match what the WIN32 half of the #ifdef does.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      25043d8a
    • J
      transport: drop "int cmp = cmp" hack · c5d5c9a9
      Jeff King 提交于
      According to 47ec7943, this initialization is meant to
      squelch an erroneous uninitialized variable warning from gcc
      4.0.1.  That version is quite old at this point, and gcc 4.1
      and up handle it fine, with one exception. There seems to be
      a regression in gcc 4.6.3, which produces the warning;
      however, gcc versions 4.4.7 and 4.7.2 do not.
      Signed-off-by: NJeff King <peff@peff.net>
      Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c5d5c9a9
    • J
      drop some obsolete "x = x" compiler warning hacks · cbfd5e1c
      Jeff King 提交于
      In cases where the setting and access of a variable are
      protected by the same conditional flag, older versions of
      gcc would generate a "might be used unitialized" warning. We
      silence the warning by initializing the variable to itself,
      a hack that gcc recognizes.
      
      Modern versions of gcc are smart enough to get this right,
      going back to at least version 4.3.5. gcc 4.1 does get it
      wrong in both cases, but is sufficiently old that we
      probably don't need to care about it anymore.
      Signed-off-by: NJeff King <peff@peff.net>
      Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cbfd5e1c
    • J
      fast-import: use pointer-to-pointer to keep list tail · 4db34cc1
      Jeff King 提交于
      This is shorter, idiomatic, and it means the compiler does
      not get confused about whether our "e" pointer is valid,
      letting us drop the "e = e" hack.
      Signed-off-by: NJeff King <peff@peff.net>
      Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4db34cc1
  4. 18 3月, 2013 2 次提交
  5. 17 3月, 2013 5 次提交
  6. 14 3月, 2013 1 次提交
  7. 12 3月, 2013 3 次提交