summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-03-26Merge branch 'jc/maint-reflog-expire-clean-mark-typofix' into maintLibravatar Junio C Hamano1-1/+1
In "git reflog expire", REACHABLE bit was not cleared from the correct objects. * jc/maint-reflog-expire-clean-mark-typofix: reflog: fix typo in "reflog expire" clean-up codepath
2013-03-25Start preparing for 1.8.2.1Libravatar Junio C Hamano2-1/+30
... at the same time, preparation for 1.8.1.6 also has started ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25Merge branch 'jk/graph-c-expose-symbols-for-cgit' into maintLibravatar Junio C Hamano2-30/+35
In the v1.8.0 era, we changed symbols that do not have to be global to file scope static, but a few functions in graph.c were used by CGit from sideways bypassing the entry points of the API the in-tree users use. * jk/graph-c-expose-symbols-for-cgit: Revert "graph.c: mark private file-scope symbols as static"
2013-03-25Merge branch 'maint-1.8.1' into maintLibravatar Junio C Hamano10-23/+64
* maint-1.8.1: bundle: Add colons to list headings in "verify" bundle: Fix "verify" output if history is complete Documentation: filter-branch env-filter example git-filter-branch.txt: clarify ident variables usage git-compat-util.h: Provide missing netdb.h definitions describe: Document --match pattern format Documentation/githooks: Explain pre-rebase parameters update-index: list supported idx versions and their features diff-options: unconfuse description of --color read-cache.c: use INDEX_FORMAT_{LB,UB} in verify_hdr() index-format.txt: mention of v4 is missing in some places
2013-03-25Merge branch 'lf/bundle-verify-list-prereqs' into maint-1.8.1Libravatar Junio C Hamano1-5/+5
"git bundle verify" did not say "records a complete history" for a bundle that does not have any prerequisites. * lf/bundle-verify-list-prereqs: bundle: Add colons to list headings in "verify" bundle: Fix "verify" output if history is complete
2013-03-25Merge branch 'tk/doc-filter-branch' into maint-1.8.1Libravatar Junio C Hamano1-2/+25
Add an example use of "--env-filter" in "filter-branch" documentation. * tk/doc-filter-branch: Documentation: filter-branch env-filter example git-filter-branch.txt: clarify ident variables usage
2013-03-25Merge branch 'dm/ni-maxhost-may-be-missing' into maint-1.8.1Libravatar Junio C Hamano2-4/+11
Some sources failed to compile on systems that lack NI_MAXHOST in their system header. * dm/ni-maxhost-may-be-missing: git-compat-util.h: Provide missing netdb.h definitions
2013-03-25Merge branch 'gp/describe-match-uses-glob-pattern' into maint-1.8.1Libravatar Junio C Hamano1-2/+3
The "--match=<pattern>" argument "git describe" takes uses glob pattern but it wasn't obvious from the documentation. * gp/describe-match-uses-glob-pattern: describe: Document --match pattern format
2013-03-25Merge branch 'nd/doc-index-format' into maint-1.8.1Libravatar Junio C Hamano3-5/+13
The v4 index format was not documented. * nd/doc-index-format: update-index: list supported idx versions and their features read-cache.c: use INDEX_FORMAT_{LB,UB} in verify_hdr() index-format.txt: mention of v4 is missing in some places
2013-03-25Merge branch 'wk/doc-pre-rebase' into maint-1.8.1Libravatar Junio C Hamano1-3/+5
The arguments given to pre-rebase hook were not documented. * wk/doc-pre-rebase: Documentation/githooks: Explain pre-rebase parameters
2013-03-25Merge branch 'jc/color-diff-doc' into maint-1.8.1Libravatar Junio C Hamano1-2/+2
The "--color=<when>" argument to the commands in the diff family was described poorly. * jc/color-diff-doc: diff-options: unconfuse description of --color
2013-03-25transport.c: help gcc 4.6.3 users by squelching compiler warningLibravatar Junio C Hamano1-1/+2
To a human reader, it is quite obvious that cmp is assigned before it is used, but gcc 4.6.3 that ships with Ubuntu 12.04 is among those that do not get this right. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21diff.c: diff.renamelimit => diff.renameLimit in messageLibravatar Max Nanasy1-1/+1
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: Max Nanasy <max.nanasy@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21wt-status: fix possible use of uninitialized variableLibravatar Jeff King1-1/+4
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21fast-import: clarify "inline" logic in file_change_mLibravatar Jeff King1-1/+2
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21run-command: always set failed_errno in start_commandLibravatar Jeff King1-2/+3
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21transport: drop "int cmp = cmp" hackLibravatar Jeff King1-1/+1
According to 47ec794, 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: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21drop some obsolete "x = x" compiler warning hacksLibravatar Jeff King2-2/+2
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: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21fast-import: use pointer-to-pointer to keep list tailLibravatar Jeff King1-6/+4
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: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-17Merge branch 'maint'Libravatar Junio C Hamano1-0/+4
* maint: t1507: Test that branchname@{upstream} is interpreted as branch
2013-03-17t1507: Test that branchname@{upstream} is interpreted as branchLibravatar Kacper Kornet1-0/+4
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: Kacper Kornet <draenog@pld-linux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-17Merge branch 'maint'Libravatar Junio C Hamano3-38/+31
* 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
2013-03-17rev-parse: clarify documentation of $name@{upstream} syntaxLibravatar Kacper Kornet1-4/+4
"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: Kacper Kornet <draenog@pld-linux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-17sha1_name: pass object name length to diagnose_invalid_sha1_path()Libravatar René Scharfe1-18/+14
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: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-16Makefile: keep LIB_H entries together and sortedLibravatar René Scharfe1-16/+13
As a follow-up to 60d24dd25 (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: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-13Git 1.8.2Libravatar Junio C Hamano2-1/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-11Merge branch 'maint'Libravatar Junio C Hamano1-2/+2
* maint: git.c: make usage match manual page
2013-03-11git.c: make usage match manual pageLibravatar Kevin Bracey1-2/+2
Reorder option list in command-line usage to match the manual page. Also make it less than 80-characters wide. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-11Merge branch 'mp/complete-paths'Libravatar Junio C Hamano1-5/+11
* mp/complete-paths: git-completion.bash: zsh does not implement function redirection correctly
2013-03-11Merge branch 'mm/add-u-A-finishing-touches'Libravatar Junio C Hamano1-3/+3
* mm/add-u-A-finishing-touches: add: update pathless 'add [-u|-A]' warning to reflect change of plan
2013-03-11git-completion.bash: zsh does not implement function redirection correctlyLibravatar Matthieu Moy1-5/+11
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: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-11Merge branch 'gp/add-u-A-documentation'Libravatar Junio C Hamano1-10/+12
* gp/add-u-A-documentation: add: Clarify documentation of -A and -u
2013-03-11add: update pathless 'add [-u|-A]' warning to reflect change of planLibravatar Matthieu Moy1-3/+3
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: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-10Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Translate git_more_info_string consistently
2013-03-10Translate git_more_info_string consistentlyLibravatar Kevin Bracey1-1/+1
"git help" translated the "See 'git help <command>' for more information..." message, but "git" didn't. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-09Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: perf: update documentation of GIT_PERF_REPEAT_COUNT
2013-03-09perf: update documentation of GIT_PERF_REPEAT_COUNTLibravatar Antoine Pelisse1-1/+1
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: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-08Merge git://git.bogomips.org/git-svnLibravatar Junio C Hamano1-1/+6
* git://git.bogomips.org/git-svn: git svn: consistent spacing after "W:" in warnings git svn: ignore partial svn:mergeinfo
2013-03-08Update draft release notes to 1.8.2Libravatar Junio C Hamano1-26/+34
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: Junio C Hamano <gitster@pobox.com>
2013-03-08bundle: Add colons to list headings in "verify"Libravatar Lukas Fleischer1-4/+4
These slightly improve the reading flow by making it obvious that a list follows. Also, make the wording of both headings consistent by changing "contains %d ref(s)" to "contains this ref"/"contains these %d refs". Signed-off-by: Lukas Fleischer <git@cryptocrack.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-08git svn: consistent spacing after "W:" in warningsLibravatar Eric Wong1-1/+1
All other instances of "W:"-prefixed warning messages have a space after the "W:" to help with readability. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-03-08git svn: ignore partial svn:mergeinfoLibravatar Jan Pešta1-0/+5
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: Jan Pesta <jan.pesta@certicon.cz> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-03-07bundle: Fix "verify" output if history is completeLibravatar Lukas Fleischer1-1/+1
A more informative message for "complete" bundles was added in commit 8c3710fd3011 (tweak "bundle verify" of a complete history, 2012-06-04). However, the prerequisites ref list is currently read *after* we check if it equals zero, which means we never actually use the number of prerequisite refs to decide when to print the newly introduced message. The code incorrectly uses the number of references recorded in the bundle instead. Signed-off-by: Lukas Fleischer <git@cryptocrack.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-07Git 1.8.2-rc3Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-07Merge git://github.com/git-l10n/git-poLibravatar Junio C Hamano5-27/+29
* '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)
2013-03-07Merge branch 'mp/complete-paths'Libravatar Junio C Hamano1-0/+9
* mp/complete-paths: git-completion.zsh: define __gitcomp_file compatibility function
2013-03-07Merge branch 'maint'Libravatar Junio C Hamano1-3/+0
* maint: gitweb/README: remove reference to git.kernel.org
2013-03-07Merge branch 'mh/maint-ceil-absolute' into maintLibravatar Junio C Hamano3-16/+52
* mh/maint-ceil-absolute: Provide a mechanism to turn off symlink resolution in ceiling paths
2013-03-07gitweb/README: remove reference to git.kernel.orgLibravatar Fredrik Gustafsson1-3/+0
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: Fredrik Gustafsson <iveqy@iveqy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-07add: Clarify documentation of -A and -uLibravatar Greg Price1-10/+12
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: Greg Price <price@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>