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>
The translation of "completed with %d local objects" is put in a
48-byte buffer, which may be enough for English but not true for any
translations. Convert it to use strbuf (i.e. no hard limit on
translation length).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce advice.statusUoption to suggest considering use of -u to
strike different trade-off when it took more than 2 seconds to
enumerate untracked/ignored files.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some repostories users experience that "git status" command takes
long time. The command spends some time searching the file system
for untracked files.
Explain the trade-off struck by the default choice of `normal` to
help users make an appropriate choice better, before talking about
the configuration variable.
Inspired by Torsten Bögershausen.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
"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>
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>
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>
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>
We describe what gets pushed by default when the command line does
not give any <refspec> under the bullet point of <refspec>.
It is a bit unfriendly to expect users to read on <refspec> when
they are not giving any in the first place. "What gets pushed" is
determined by taking many factors (<refspec> argument being only one
of them) into account, and is a property of the entire command, not
an individual argument. Also we do not describe "Where the push
goes" when the command line does not say.
Give the description on "what gets pushed to where" upfront before
explaining individual arguments and options.
Also update the description of <refspec> to say what it is, what it
is used for, before explaining what shape it takes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
A more informative message for "complete" bundles was added in commit
8c3710fd30 (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>
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>
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>
In "reflog expire" we were not clearing the REACHABLE bit from
objects reachable from the tip of refs we marked earlier.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
Previously when using update with recursion, only the path for the
inner-most module was printed. Now the path is printed relative to
the directory the command was started from. This now matches the
behavior of submodule foreach.
Signed-off-by: William Entriken <github.com@phor.net>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit ba35480439.
CGit uses these symbols to output the correct HTML around graph
elements. Making these symbols private means that CGit cannot be
updated to use Git 1.8.0 or newer, so let's not do that.
On top of the revert, also add comments so that we avoid reintroducing
this problem in the future and suggest to those modifying this API
that they might want to discuss it with the CGit developers.
Signed-off-by: John Keeping <john@keeping.me.uk>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A maildir does not technically record the order in which
items were placed into it. That means that when applying a
patch series from a maildir, we may get the patches in the
wrong order. We try to work around this by sorting the
filenames. Unfortunately, this may or may not work depending
on the naming scheme used by the writer of the maildir.
For instance, mutt will write:
${epoch_seconds}.${pid}_${seq}.${host}
where we have:
- epoch_seconds: timestamp at which entry was written
- pid: PID of writing process
- seq: a sequence number to ensure uniqueness of filenames
- host: hostname
None of the numbers are zero-padded. Therefore, when we sort
the names as byte strings, entries that cross a digit
boundary (e.g., 10) will sort out of order. In the case of
timestamps, it almost never matters (because we do not cross
a digit boundary in the epoch time very often these days).
But for the sequence number, a 10-patch series would be
ordered as 1, 10, 2, 3, etc.
To fix this, we can use a custom sort comparison function
which traverses each string, comparing chunks of digits
numerically, and otherwise doing a byte-for-byte comparison.
That would sort:
123.456_1.bar
123.456_2.bar
...
123.456_10.bar
according to the sequence number. Since maildir does not
define a filename format, this is really just a heuristic.
But it happens to work for mutt, and there is a reasonable
chance that it will work for other writers, too (at least as
well as a straight sort).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
* 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'
