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'
An earlier workaround designed to help people who list logical
directories that will not match what getcwd(3) returns in the
GIT_CEILING_DIRECTORIES had an adverse effect when it is slow to
stat and readlink a directory component of an element listed on it.
* mh/maint-ceil-absolute:
Provide a mechanism to turn off symlink resolution in ceiling paths
Currently ZIP archive entries of files with export-subst attribute are
broken if they are stored uncompressed.
We get the size of a file from sha1_object_info(), but this number is
likely wrong for files whose contents are changed due to export-subst
placeholder expansion. We use sha1_file_to_archive() to get the
expanded file contents and size in that case. We proceed to use that
size for the uncompressed size field (good), but the compressed size
field is set based on the size from sha1_object_info() (bad).
This matters only for uncompressed files because for deflated files
we use the correct value after compression is done. And for files
without export-subst expansion the sizes from sha1_object_info() and
sha1_file_to_archive() are the same, so they are unaffected as well.
This patch fixes the issue by setting the compressed size based on the
uncompressed size only after we actually know the latter.
Also make use of the test file substfile1 to check for the breakage;
it was only stored verbatim so far. For that purpose, set the
attribute export-subst and replace its contents with the expected
expansion after committing.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In commit 9db31bdf (submodule: Add --force option for git submodule
update, 2011-04-01) we added the option to the implementation's usage
synopsis but forgot to add it to the synopsis in the command
documentation. Add the option to the synopsis in the same location it
is reported in usage and re-wrap the options to avoid long lines.
Signed-off-by: Brad King <brad.king@kitware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
filter-branch --env-filter example that shows how to change the email
address in all commits before publishing a project.
Signed-off-by: Tadeusz Andrzej Kadłubowski <yess@hell.org.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
