Commit Graph

32110 Commits

Author SHA1 Message Date
Yann Droneaud
55adef0650 t3400: use test_config to set/unset git config variables
Instead of using construct such as:
    test_when_finished "git config --unset <key>"
    git config <key> <value>
uses
    test_config <key> <value>
The latter takes care of removing <key> at the end of the test.

Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25 08:50:53 -07:00
Max Nanasy
c9fc4415e2 diff.c: diff.renamelimit => diff.renameLimit in message
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-21 14:06:49 -07:00
Jeff King
b8527d5fa6 wt-status: fix possible use of uninitialized variable
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-21 14:06:49 -07:00
Jeff King
3aa99df802 fast-import: clarify "inline" logic in file_change_m
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-21 14:06:49 -07:00
Jeff King
25043d8aea run-command: always set failed_errno in start_command
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-21 14:06:48 -07:00
Jeff King
c5d5c9a9a3 transport: drop "int cmp = cmp" hack
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-21 14:06:44 -07:00
Jeff King
cbfd5e1cbb drop some obsolete "x = x" compiler warning hacks
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-21 14:06:38 -07:00
Jeff King
4db34cc134 fast-import: use pointer-to-pointer to keep list tail
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-21 14:06:19 -07:00
Junio C Hamano
1c71541ddd Merge branch 'maint'
* maint:
  t1507: Test that branchname@{upstream} is interpreted as branch
2013-03-17 15:39:43 -07:00
Kacper Kornet
617cf93182 t1507: Test that branchname@{upstream} is interpreted as branch
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-17 15:38:23 -07:00
Junio C Hamano
bb79a827a2 Merge branch 'maint'
* 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-17 00:11:11 -07:00
Kacper Kornet
47e329ef7c rev-parse: clarify documentation of $name@{upstream} syntax
"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-17 00:10:59 -07:00
René Scharfe
b2981d0622 sha1_name: pass object name length to diagnose_invalid_sha1_path()
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-17 00:10:51 -07:00
René Scharfe
ea738e2da1 Makefile: keep LIB_H entries together and sorted
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-16 22:23:04 -07:00
Junio C Hamano
239222f587 Git 1.8.2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-13 11:28:08 -07:00
Junio C Hamano
ce432cac30 Merge branch 'maint'
* maint:
  git.c: make usage match manual page
2013-03-11 13:00:16 -07:00
Kevin Bracey
03a0fb0ccf git.c: make usage match manual page
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-11 12:59:57 -07:00
Junio C Hamano
f1eba9f055 Merge branch 'mp/complete-paths'
* mp/complete-paths:
  git-completion.bash: zsh does not implement function redirection correctly
2013-03-11 10:32:16 -07:00
Junio C Hamano
c75aa630b2 Merge branch 'mm/add-u-A-finishing-touches'
* mm/add-u-A-finishing-touches:
  add: update pathless 'add [-u|-A]' warning to reflect change of plan
2013-03-11 10:32:03 -07:00
Matthieu Moy
35ba83ccf6 git-completion.bash: zsh does not implement function redirection correctly
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💿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-11 10:22:56 -07:00
Junio C Hamano
ca8df3df8c Merge branch 'gp/add-u-A-documentation'
* gp/add-u-A-documentation:
  add: Clarify documentation of -A and -u
2013-03-11 08:11:38 -07:00
Matthieu Moy
c6898ebf21 add: update pathless 'add [-u|-A]' warning to reflect change of plan
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-11 07:57:35 -07:00
Junio C Hamano
0c91a6f302 Merge branch 'maint'
* maint:
  Translate git_more_info_string consistently
2013-03-10 22:29:29 -07:00
Kevin Bracey
421a976945 Translate git_more_info_string consistently
"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-10 13:11:31 -07:00
Junio C Hamano
407929cb45 Merge branch 'maint'
* maint:
  perf: update documentation of GIT_PERF_REPEAT_COUNT
2013-03-09 11:54:05 -08:00
Antoine Pelisse
ca70c9ea72 perf: update documentation of GIT_PERF_REPEAT_COUNT
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-09 11:13:12 -08:00
Junio C Hamano
1cc625fd7a Merge git://git.bogomips.org/git-svn
* git://git.bogomips.org/git-svn:
  git svn: consistent spacing after "W:" in warnings
  git svn: ignore partial svn:mergeinfo
2013-03-08 14:15:55 -08:00
Junio C Hamano
3e714cdbab Update draft release notes to 1.8.2
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-08 14:14:27 -08:00
Eric Wong
eae6cf5aa8 git svn: consistent spacing after "W:" in warnings
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-08 09:53:57 +00:00
Jan Pešta
47543d161e git svn: ignore partial svn:mergeinfo
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-08 09:46:03 +00:00
Junio C Hamano
aadb70a559 Git 1.8.2-rc3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-07 13:14:39 -08:00
Junio C Hamano
cde47b9dce Merge git://github.com/git-l10n/git-po
* '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-07 13:12:34 -08:00
Junio C Hamano
c5443b2a1e Merge branch 'mp/complete-paths'
* mp/complete-paths:
  git-completion.zsh: define __gitcomp_file compatibility function
2013-03-07 13:11:55 -08:00
Junio C Hamano
e53e8dd9bc Merge branch 'maint'
* maint:
  gitweb/README: remove reference to git.kernel.org
2013-03-07 12:50:36 -08:00
Junio C Hamano
5d4ef1721a Merge branch 'mh/maint-ceil-absolute' into maint
* mh/maint-ceil-absolute:
  Provide a mechanism to turn off symlink resolution in ceiling paths
2013-03-07 12:49:57 -08:00
Fredrik Gustafsson
80659ff47b gitweb/README: remove reference to git.kernel.org
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-07 11:38:33 -08:00
Greg Price
5cae935660 add: Clarify documentation of -A and -u
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>
2013-03-07 11:16:54 -08:00
Jiang Xin
a7409dfbc1 l10n: zh_CN.po: translate 1 new message
Translate 1 new message came from git.pot update in ed1ddaf
(l10n: git.pot: v1.8.2 round 4 (1 changed)).

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2013-03-07 08:46:19 +08:00
Ralf Thielow
79d0f37337 l10n: de.po: translate 1 new message
Translate 1 new message came from git.pot update in
ed1ddaf (l10n: git.pot: v1.8.2 round 4 (1 changed)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2013-03-06 19:26:29 +01:00
Tran Ngoc Quan
3fef5536a0 l10n: vi.po: Update translation (2009t0f0u)
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2013-03-06 13:57:17 +07:00
Matthieu Moy
926eb7ba4c git-completion.zsh: define __gitcomp_file compatibility function
Commit fea16b47b6 (Fri Jan 11 19:48:43 2013, Manlio Perillo,
git-completion.bash: add support for path completion), introduced a new
__gitcomp_file function that uses the bash builtin "compgen". The
function was redefined for ZSH in the deprecated section of
git-completion.bash, but not in the new git-completion.zsh script.

As a result, users of git-completion.zsh trying to complete "git add
fo<tab>" get an error:

git add fo__gitcomp_file:8: command not found: compgen

This patch adds the redefinition and removes the error.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-05 08:54:03 -08:00
Peter Krefting
b6eab8bdaa l10n: Update Swedish translation (2009t0f0u)
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2013-03-05 09:18:25 +01:00
Jiang Xin
ed1ddafa60 l10n: git.pot: v1.8.2 round 4 (1 changed)
Generate po/git.pot from v1.8.2-rc2-4-g77995 for git v1.8.2
l10n round 4.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2013-03-05 12:41:45 +08:00
Junio C Hamano
7799588faa Merge git://github.com/git-l10n/git-po
* git://github.com/git-l10n/git-po:
  l10n: de.po: correct translation of "bisect" messages
  l10n: de.po: translate 5 new messages
  l10n: de.po: translate 35 new messages
2013-03-04 01:16:02 -08:00
Junio C Hamano
4d0d0c3c59 Git 1.8.2-rc2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-03 01:24:11 -08:00
Junio C Hamano
06d67b8766 Sync with 1.8.1.5 2013-03-01 13:17:18 -08:00
Junio C Hamano
e6363a4992 Git 1.8.1.5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-01 13:15:29 -08:00
Thomas Rast
8b1bd02415 Make !pattern in .gitattributes non-fatal
Before 82dce99 (attr: more matching optimizations from .gitignore,
2012-10-15), .gitattributes did not have any special treatment of a
leading '!'.  The docs, however, always said

  The rules how the pattern matches paths are the same as in
  `.gitignore` files; see linkgit:gitignore[5].

By those rules, leading '!' means pattern negation.  So 82dce99
correctly determined that this kind of line makes no sense and should
be disallowed.

However, users who actually had a rule for files starting with a '!'
are in a bad position: before 82dce99 '!' matched that literal
character, so it is conceivable that users have .gitattributes with
such lines in them.  After 82dce99 the unescaped version was
disallowed in such a way that git outright refuses to run(!) most
commands in the presence of such a .gitattributes.  It therefore
becomes very hard to fix, let alone work with, such repositories.

Let's at least allow the users to fix their repos: change the fatal
error into a warning.

Reported-by: mathstuf@gmail.com
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-01 12:24:45 -08:00
Junio C Hamano
1d38c6971d Merge branch 'wk/user-manual' into maint
* wk/user-manual:
  user-manual: Flesh out uncommitted changes and submodule updates
  user-manual: Use request-pull to generate "please pull" text
  user-manual: Reorganize the reroll sections, adding 'git rebase -i'
2013-03-01 10:37:40 -08:00
Andrew Wong
5e2485846d Documentation/githooks: Fix linkgit
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-01 10:19:22 -08:00