The config variables are mentioned within the descriptions of the
command line options with which they are associated.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There is also now a configuration variable:
sendemail[.<identity>].validate
Signed-off-by: Michael Witten <mfwitten@mit.edu>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now the man page lists the options in alphabetical
order (in terms of the 'main' part of an option's
name).
Signed-off-by: Michael Witten <mfwitten@mit.edu>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Specifically, boolean options are now listed in the form
--[no-]option
and both forms of documentation now consistently use
--[no-]signed-off-by-cc
Signed-off-by: Michael Witten <mfwitten@mit.edu>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The need for "--" in the git-log synopsis was previously unclear and
confusing. This patch makes it a little clearer.
Thanks to hyy <yiyihu@gmail.com> for his help.
[sp: Changed -- to \-- per prior commit e1ccf53.]
Signed-off-by: martin f. krafft <madduck@madduck.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
... because they show up in the man and html outputs.
This escaping is only needed for double dashes to be compatible with
older asciidoc versions; see commit e1ccf53 ([PATCH] Escape asciidoc's
built-in em-dash replacement, 2005-09-12).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
foo.org is an existing domain, use RFC 2606 complying example.com instead
as used in other docs as well.
Signed-off-by: Michael Prokop <mika@grml.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The process of overriding the default LESS options using only
git-specific methods is rather obscure. Show the end user how
to do it in a step-by-step manner.
Signed-off-by: Chris Frey <cdfrey@foursquare.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In the future, I think we should also default to xdg-open on Linux instead
of having a KDE-specific hack.
This patch has been sponsored by Novartis.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Generally, the dependent clause "for example" is suffixed with a comma.
Used present tense where appropriate to be consistent with the other
paragraphs.
Rewrote the paragraph in the second hunk to be more clear.
Signed-off-by: Garry Dolley <gdolley@ucla.edu>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This concept was retired by 77882f6 (Retire diffcore-pathspec.,
2006-04-10), more than 2 years ago.
Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, the hunk headers produced by 'diff -p' are customizable by
setting the diff.*.funcname option in the config file. The 'funcname' option
takes a basic regular expression. This functionality was designed using the
GNU regex library which, by default, allows using backslashed versions of
some extended regular expression operators, even in Basic Regular Expression
mode. For example, the following characters, when backslashed, are
interpreted according to the extended regular expression rules: ?, +, and |.
As such, the builtin funcname patterns were created using some extended
regular expression operators.
Other platforms which adhere more strictly to the POSIX spec do not
interpret the backslashed extended RE operators in Basic Regular Expression
mode. This causes the pattern matching for the builtin funcname patterns to
fail on those platforms.
Introduce a new option 'xfuncname' which uses extended regular expressions,
and advertise it _instead_ of funcname. Since most users are on GNU
platforms, the majority of funcname patterns are created and tested there.
Advertising only xfuncname should help to avoid the creation of non-portable
patterns which work with GNU regex but not elsewhere.
Additionally, the extended regular expressions may be less ugly and
complicated compared to the basic RE since many common special operators do
not need to be backslashed.
For example, the GNU Basic RE:
^[ ]*\\(\\(public\\|static\\).*\\)$
becomes the following Extended RE:
^[ ]*((public|static).*)$
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The only part of the hunk header that we can change is the "TEXT"
portion. Additionally, a few grammatical errors have been corrected.
Signed-off-by: Garry Dolley <gdolley@ucla.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch introduces a make target "quick-install-html" which installs
the html documentation from the branch origin/html, without the need for
asciidoc/xmlto. This is analogous to the existing "quick-install-doc"
target for the man pages.
We advertise these targets in the INSTALL file now.
Signed-off-by: Michael J Gruber <michaeljgruber+gmane@fastmail.fm>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The logic to checkout a different commit implements the safety to never
lose user's local changes. For example, switching from a commit to
another commit, when you have changed a path that is different between
them, need to merge your changes to the version from the switched-to
commit, which you may not necessarily be able to resolve easily. By
default, "git checkout" refused to switch branches, to give you a chance
to stash your local changes (or use "-m" to merge, accepting the risks of
getting conflicts).
This safety, however, had one deliberate hole since early June 2005. When
your local change was to remove a path (and optionally to stage that
removal), the command checked out the path from the switched-to commit
nevertheless.
This was to allow an initial checkout to happen smoothly (e.g. an initial
checkout is done by starting with an empty index and switching from the
commit at the HEAD to the same commit). We can tighten the rule slightly
to allow this special case to pass, without losing sight of removal
explicitly done by the user, by noticing if the index is truly empty when
the operation begins.
For historical background, see:
http://thread.gmane.org/gmane.comp.version-control.git/4641/focus=4646
This case is marked as *0* in the message, which both Linus and I said "it
feels somewhat wrong but otherwise we cannot start from an empty index".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise it will always print the class-name rather
than the name of the function inside that class.
While we're at it, reorder the gitattributes manpage to
list the built-in funcname pattern names in alphabetical
order.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows --include=pathspec, similar to --exclude=pathspec.
The rule when one or both of these are used is that the include/exclude
patterns are examined in the order they are given on the command line, and
the first match determines if a patch to each path is used or not. Hence:
$ git apply --include='specific.h' --exclude='*.h' <diff
would apply the patch to specific.h header file, but all other patches in
the input file to other header files are ignored. A patch to a path that
does not match any include/exclude pattern is used by default if there is
no include pattern on the command line, and ignored if there is any
include pattern.
This originally came from Joe Perches, but both the design of the
semantics and the implementation have been redone complately.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tries to shorten the refname to a non-ambiguous name.
Szeder Gábor noticed that the git bash completion takes a
tremendous amount of time to strip leading components from
heads and tags refs (i.e. refs/heads, refs/tags, ...). He
proposed a new atom called 'refbasename' which removes at
most two leading components from the ref name.
I myself, proposed a more dynamic solution, which strips off
common leading components with the matched pattern.
But the current bash solution and both proposals suffer from
one mayor problem: ambiguous refs.
A ref is ambiguous, if it resolves to more than one full refs.
I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The
(short) ref xyzzy can point to both refs.
( Note: Its irrelevant whether the referenced objects are the
same or not. )
This proposal solves this by checking for ambiguity of the
shorten ref name.
The shortening is done with the same rules for resolving refs
but in the reverse order. The short name is checked if it
resolves to a different ref.
To continue the above example, the output would be like this:
heads/xyzzy
xyzzy
So, if you want just tags, xyzzy is not ambiguous, because it
will resolve to a tag. If you need the heads you get a also
a non-ambiguous short form of the ref.
To integrate this new format into the bash completion to get
only non-ambiguous refs is beyond the scope of this patch.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new option --dirstat-by-file is the same as --dirstat, but it
counts "impacted files" instead of "impacted lines" (lines that are
added or removed).
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When somebody is reading git-blame.txt (or git-annotate.txt) for the first
time, the message we would like to send is:
(1) Here is why you would want to use this command, what it can do
(perhaps more than what you would have expected from "$scm blame"),
and how you tell it to do what it does.
This is obvious.
(2) You might have heard of the command with the other name. There is no
difference between the two, except they differ in their default
output formats.
This is essential to answer: "git has both? how are they different?"
(3) We tend to encourage blame over annotate for new scripts and new
people, but there is no reason to choose one over the other.
This is not as important as (2), but would be useful to avoid
repeated questions about "when will we start deprecating this?"
As long as we describe (2) on git-annotate page clearly enough, people who
read git-blame page first and get curious can refer to git-annotate page.
While at it, subtly hint (3) without being overly explicit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a new format placeholder, %d, which expands to a ref name decoration
(think git log --decorate). It expands to an empty string if the commit
has no decoration, or otherwise to a comma (and space) separated list of
decorations, surrounded by parentheses and a leading space.
Michael Dressel implemented an initial version and chose the letter d,
Junio suggested to add a leading space and parentheses.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the section on conflict markers, the "<<<<<<<" sequence is compiled by
AsciiDoc into invalid XML. A way to resolve this is by inserting something
between the last two characters in that sequence (i.e. between '<' and '"').
This patch encloses the conflict markers in backticks, which renders them
in a monospace font (in the HTML version; the manual page is unaffected),
and with the pleasant side-effect that it also fixes the AsciiDoc compile
problem.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no need to explicitly pass the file to be committed to 'git
commit', because it's contents is already in the index.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Asciidoc removes lines starting with a dot when creating manpages.
Since those lines were comments in use case examples showing shell
commands, preceed those lines with a hash sign.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We took it granted that everybody knows how to read the RCS merge style
conflicts, and did not give illustrations in the documentation. Now we
are introducing an alternative output style, it is time to document this.
The lack of illustration has been bugging me for a long time.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new option does essentially the same thing as -m option when checking
unmerged paths out of the index, but it uses the specified style instead
of configured merge.conflictstyle.
Setting "merge.conflictstyle" to "diff3" is usually less useful than using
the default "merge" style, because the latter allows a conflict that
results by both sides changing the same region in a very similar way to
get simplified substancially by reducing the common lines. However, when
one side removed a group of lines (perhaps a function was moved to some
other file) while the other side modified it, the default "merge" style
does not give any clue as to why the hunk is left conflicting. You would
need the original to understand what is going on.
The recommended use would be not to set merge.conflictstyle variable so
that you would usually use the default "merge" style conflict, and when
the result in a path in a particular merge is too hard to understand, use
"git checkout --conflict=diff3 $path" to check it out with the original to
review what is going on.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The SYNOPSIS section of gitattibutes and gitmodule fail to clearly
specify the name of the in tree files used. This patch brings in the
initial `.' and the fact that the `.gitmodules' file should reside at
the top-level of the working tree.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is off(0) by default, to avoid scaring people unless they asked to.
If set to a non-0 value, wait for that amount of deciseconds before
running the corrected command.
Suggested by Junio, so he has a chance to hit Ctrl-C.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitcvs.usecrlfattr --> gitcvs.usecrlfattr::
This fixes an asciidoc markup issue.
Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows "git commit --author=$name" to accept a name that is not in
the required "A U Thor <author@example.xz>" format, and use that to look
up an author name that matches from existing commits.
When using this feature, it is the user's responsibility to give a name
that uniquely matches the name s/he wants, as the logic returns the name
from the first matching commit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With a new configuration "diff.mnemonicprefix", "git diff" shows the
differences between various combinations of preimage and postimage trees
with prefixes different from the standard "a/" and "b/". Hopefully this
will make the distinction stand out for some people.
"git diff" compares the (i)ndex and the (w)ork tree;
"git diff HEAD" compares a (c)ommit and the (w)ork tree;
"git diff --cached" compares a (c)ommit and the (i)ndex;
"git-diff HEAD:file1 file2" compares an (o)bject and a (w)ork tree entity;
"git diff --no-index a b" compares two non-git things (1) and (2).
Because these mnemonics now have meanings, they are swapped when reverse
diff is in effect and this feature is enabled.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The description of crlf attribute incorrectly said that "-crlf" means
binary. It is true that for binary files you would want "-crlf", but
that is not the same thing.
We also have supported attribute macros and via that mechanism a handy
"binary" to specify "-crlf -diff" at the same time. It was not documented
anywhere as far as I can tell, even though the support was there from
the very beginning.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches git-checkout to recreate a merge out of unmerged
index entries while resolving conflicts.
With this patch, checking out an unmerged path from the index
now have the following possibilities:
* Without any option, an attempt to checkout an unmerged path
will atomically fail (i.e. no other cleanly-merged paths are
checked out either);
* With "-f", other cleanly-merged paths are checked out, and
unmerged paths are ignored;
* With "--ours" or "--theirs, the contents from the specified
stage is checked out;
* With "-m" (we should add "--merge" as synonym), the 3-way merge
is recreated from the staged object names and checked out.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Witten