Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 23 3月, 2013 1 次提交
    • J
      submodule: clarify logic in show_submodule_summary · 83715497
      由 Jeff King 提交于 
      There are two uses of the "left" and "right" commit variables that
make it hard to be sure what values they have (both for the reader,
and for gcc, which wrongly complains that they might be used
uninitialized).

The function starts with a cascading if statement, checking that the
input sha1s exist, and finally working up to preparing a revision
walk. We only prepare the walk if the cascading conditional did not
find any problems, which we check by seeing whether it set the
"message" variable or not. It's simpler and more obvious to just add
a condition to the end of the cascade.

Later, we check the same "message" variable when deciding whether to
clear commit marks on the left/right commits; if it is set, we
presumably never started the walk. This is wrong, though; we might
have started the walk and munged commit flags, only to encounter an
error afterwards. We should always clear the flags on left/right if
they exist, whether the walk was successful or not.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      83715497
  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
  5. 18 3月, 2013 2 次提交
  7. 17 3月, 2013 4 次提交
  9. 14 3月, 2013 1 次提交
  11. 12 3月, 2013 5 次提交
    • J
      Merge branch 'maint' · ce432cac
      由 Junio C Hamano 提交于 
      * maint:
  git.c: make usage match manual page
      ce432cac
    • K
      git.c: make usage match manual page · 03a0fb0c
      由 Kevin Bracey 提交于 
      Reorder option list in command-line usage to match the manual page.
Also make it less than 80-characters wide.
Signed-off-by: NKevin Bracey <kevin@bracey.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      03a0fb0c
    • J
      Merge branch 'mp/complete-paths' · f1eba9f0
      由 Junio C Hamano 提交于 
      * mp/complete-paths:
  git-completion.bash: zsh does not implement function redirection correctly
      f1eba9f0
    • J
      Merge branch 'mm/add-u-A-finishing-touches' · c75aa630
      由 Junio C Hamano 提交于 
      * mm/add-u-A-finishing-touches:
  add: update pathless 'add [-u|-A]' warning to reflect change of plan
      c75aa630
    • M
      git-completion.bash: zsh does not implement function redirection correctly · 35ba83cc
      由 Matthieu Moy 提交于 
      A recent change added functions whose entire standard error stream
is redirected to /dev/null using a construct that is valid POSIX.1
but is not widely used:

	funcname () {
		cd "$1" && run some command "$2"
	} 2>/dev/null

Even though this file is "git-completion.bash", zsh completion
support dot-sources it (instead of asking bash to grok it like tcsh
completion does), and zsh does not implement this redirection
correctly.

With zsh, trying to complete an inexistant directory gave this:

  git add no-such-dir/__git_ls_files_helper:cd:2: no such file or directory: no-such-dir/

Also these functions use "cd" to first go somewhere else before
running a command, but the location the caller wants them to go that
is given as an argument to them should not be affected by CDPATH
variable the users may have set for their interactive session.

To fix both of these, wrap the body of the function in a subshell,
unset CDPATH at the beginning of the subshell, and redirect the
standard error stream of the subshell to /dev/null.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      35ba83cc
  13. 11 3月, 2013 4 次提交
  15. 10 3月, 2013 2 次提交
  17. 09 3月, 2013 2 次提交
  19. 08 3月, 2013 9 次提交
  21. 07 3月, 2013 2 次提交
  23. 06 3月, 2013 1 次提交