- 26 3月, 2013 1 次提交
-
-
由 René Scharfe 提交于
Convert the loop in score_trees() to tree_entry(). The code becomes shorter and simpler because the calls to update_tree_entry() are not needed any more. Another benefit is that we need less variables to track the current tree entries; as a side-effect of that the compiler has an easier job figuring out the control flow and thus can avoid false warnings about uninitialized variables. Using struct name_entry also allows the use of tree_entry_len() for finding the path length instead of strlen(), which may be slightly more efficient. Also unify the handling of missing entries in one of the two trees (i.e. added or removed files): Just set cmp appropriately first, no matter if we ran off the end of a tree or if we actually have two entries to compare, and check its value a bit later without duplicating the handler code. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 3月, 2013 1 次提交
-
-
由 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>
-
- 22 3月, 2013 7 次提交
-
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
- 18 3月, 2013 2 次提交
-
-
由 Junio C Hamano 提交于
* maint: t1507: Test that branchname@{upstream} is interpreted as branch
-
由 Kacper Kornet 提交于
Syntax branchname@{upstream} should interpret its argument as a name of a branch. Add the test to check that it doesn't try to interpret it as a refname if the branch in question does not exist. Signed-off-by: NKacper Kornet <draenog@pld-linux.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 3月, 2013 4 次提交
-
-
由 Junio C Hamano 提交于
* maint: rev-parse: clarify documentation of $name@{upstream} syntax sha1_name: pass object name length to diagnose_invalid_sha1_path() Makefile: keep LIB_H entries together and sorted
-
由 Kacper Kornet 提交于
"git rev-parse" interprets string in string@{upstream} as a name of a branch not a ref. For example, refs/heads/master@{upstream} looks for an upstream branch that is merged by git-pull to ref refs/heads/refs/heads/master not to refs/heads/master. However the documentation could mislead a user to believe that the string is interpreted as ref. Signed-off-by: NKacper Kornet <draenog@pld-linux.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
The only caller of diagnose_invalid_sha1_path() extracts a substring from an object name by creating a NUL-terminated copy of the interesting part. Add a length parameter to the function and thus avoid the need for an allocation, thereby simplifying the code. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
As a follow-up to 60d24dd2 (Makefile: fold XDIFF_H and VCSSVN_H into LIB_H), let the unconditional additions to LIB_H form a single sorted list. Also drop the duplicate entry for xdiff/xdiff.h, which was easy to spot after sorting. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 3月, 2013 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 3月, 2013 5 次提交
-
-
由 Junio C Hamano 提交于
* maint: git.c: make usage match manual page
-
由 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>
-
由 Junio C Hamano 提交于
* mp/complete-paths: git-completion.bash: zsh does not implement function redirection correctly
-
由 Junio C Hamano 提交于
* mm/add-u-A-finishing-touches: add: update pathless 'add [-u|-A]' warning to reflect change of plan
-
由 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>
-
- 11 3月, 2013 4 次提交
-
-
由 Junio C Hamano 提交于
* gp/add-u-A-documentation: add: Clarify documentation of -A and -u
-
由 Matthieu Moy 提交于
We originally thought the transition would need a period where "git add [-u|-A]" without pathspec would be forbidden, but the warning is big enough to scare people and teach them not to use it (or, if so, to understand the consequences). Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* maint: Translate git_more_info_string consistently
-
由 Kevin Bracey 提交于
"git help" translated the "See 'git help <command>' for more information..." message, but "git" didn't. Signed-off-by: NKevin Bracey <kevin@bracey.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 3月, 2013 2 次提交
-
-
由 Junio C Hamano 提交于
* maint: perf: update documentation of GIT_PERF_REPEAT_COUNT
-
由 Antoine Pelisse 提交于
Currently the documentation of GIT_PERF_REPEAT_COUNT says the default is five while "perf-lib.sh" uses a value of three as a default. Update the documentation so that it is consistent with the code. Signed-off-by: NAntoine Pelisse <apelisse@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 3月, 2013 2 次提交
-
-
git://git.bogomips.org/git-svn由 Junio C Hamano 提交于
* git://git.bogomips.org/git-svn: git svn: consistent spacing after "W:" in warnings git svn: ignore partial svn:mergeinfo
-
由 Junio C Hamano 提交于
Split the backward-compatibility notes into two sections, the ones that affect this release, and the other to describe changes meant for Git 2.0. The latter gives a context to understand why the changes for this release is necessary. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 3月, 2013 9 次提交
-
-
由 Eric Wong 提交于
All other instances of "W:"-prefixed warning messages have a space after the "W:" to help with readability. Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
由 Jan Pešta 提交于
Currently this is cosmetic change - the merges are ignored, becuase the methods (lookup_svn_merge, find_rev_before, find_rev_after) are failing on comparing text with number. See http://www.open.collab.net/community/subversion/articles/merge-info.html Extract: The range r30430:30435 that was added to 1.5.x in this merge has a '*' suffix for 1.5.x\www. This '*' is the marker for a non-inheritable mergeinfo range. The '*' means that only the path on which the mergeinfo is explicitly set has had this range merged into it. Signed-off-by: NJan Pesta <jan.pesta@certicon.cz> Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
git://github.com/git-l10n/git-po由 Junio C Hamano 提交于
* 'master' of git://github.com/git-l10n/git-po: l10n: zh_CN.po: translate 1 new message l10n: de.po: translate 1 new message l10n: vi.po: Update translation (2009t0f0u) l10n: Update Swedish translation (2009t0f0u) l10n: git.pot: v1.8.2 round 4 (1 changed)
-
由 Junio C Hamano 提交于
* mp/complete-paths: git-completion.zsh: define __gitcomp_file compatibility function
-
由 Junio C Hamano 提交于
* maint: gitweb/README: remove reference to git.kernel.org
-
由 Junio C Hamano 提交于
* mh/maint-ceil-absolute: Provide a mechanism to turn off symlink resolution in ceiling paths
-
由 Fredrik Gustafsson 提交于
git.kernel.org no longer uses gitweb but has switched to cgit. Info about this can be found on: https://www.kernel.org/pelican.html or simply by looking at http://git.kernel.org . This is change since 2013-03-01. Signed-off-by: NFredrik Gustafsson <iveqy@iveqy.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Greg Price 提交于
The documentation of '-A' and '-u' is very confusing for someone who doesn't already know what they do. Describe them with fewer words and clearer parallelism to each other and to the behavior of plain 'add'. Also mention the default <pathspec> for '-A' as well as '-u', because it applies to both. Signed-off-by: NGreg Price <price@mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 3月, 2013 2 次提交
-
-
由 Jiang Xin 提交于
Translate 1 new message came from git.pot update in ed1ddafa (l10n: git.pot: v1.8.2 round 4 (1 changed)). Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
-
由 Ralf Thielow 提交于
Translate 1 new message came from git.pot update in ed1ddafa (l10n: git.pot: v1.8.2 round 4 (1 changed)). Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com>
-