We can be clever and know by ourselves when we need the behavior
implied by "--remap-to-ancestor". No need to encumber users by having
them exposed to it as a tunable. (Option kept for backward compatibility,
but it's now a no-op.)
Signed-off-by: Csaba Henk <csaba@gluster.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Older versions of AsciiDoc used to literally pass double dashes when we
used them in our linkgit macros and manpage titles, but newer ones (the
issue was first reported with AsciiDoc 8.5.2) turn them into em dashes.
Define litdd (literal double-dash) custom attribute in asciidoc.conf to
work this around. While we are at it, fix a few double-dashes (e.g. the
description of "project--devo--version" convention used by tla, among
other things) that used to be incorrectly written as em dashes in the body
text to also use this attribute.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, one could think that 'git bundle create' groks
any 'git rev-list' expression. But in fact it requires a named reference
to be present. Try and make this clearer.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cleanup various spellings of the same argument, as well as the code
for the tilde: Since neither '~' nor '\~' work consistently, use
'{tilde}'.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update the documentation to indicate that git stash branch only attempts
to drop the specified stash if it looks like stash reference.
Also changed the synopsis to more clearly indicate which commands require
a stash entry reference as opposed to merely a stash-like commit.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mm/rebase-i-exec:
git-rebase--interactive.sh: use printf instead of echo to print commit message
git-rebase--interactive.sh: rework skip_unnecessary_picks
test-lib: user-friendly alternatives to test [-d|-f|-e]
rebase -i: add exec command to launch a shell command
Conflicts:
git-rebase--interactive.sh
t/t3404-rebase-interactive.sh
* dg/local-mod-error-messages:
t7609: test merge and checkout error messages
unpack_trees: group error messages by type
merge-recursive: distinguish "removed" and "overwritten" messages
merge-recursive: porcelain messages for checkout
Turn unpack_trees_options.msgs into an array + enum
Conflicts:
t/t3400-rebase.sh
We use our custom xsl file to build the user manual, so make
sure we depend on it. We don't use it anywhere else, so we
can stick it straight in the rule.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because there is no unescaped apostrophe to pair it with, asciidoc
does not consider this apostrophe a candidate for escaping and
the backslash passes through.
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The intended text is "it's O(N * T) vs O(N * T * M)". Asciidoc
notices the spaces around the asterisks so there is no need to
escape them (and if you try, it passes the backslashes through).
Cc: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The symmetric difference or merge-base operator ... as used by
rev-list and diff is actually three period characters. If it
gets replaced by an ellipsis glyph in the manual, that would
stop readers from copying and pasting it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While at it:
- remove some single-quotes that were being rendered as ’\n\';
- do not escape ellipses (...) when they do not represent the
literal three characters "...". We may want to ensure the
manpages render these as three ASCII periods to make the
manual pages easier to search, but that would be a global
output generation setting, not a context-specific thing;
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the {asterisk} entity instead of \* or * to avoid both
stray backslashes in output and suppression of asterisks
misinterpreted as a bold-text delimiter.
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the {tilde} entity to get a literal tilde without fuss.
With \~, asciidoc 8.5.2 (and probably earlier versions) keeps the
backslash in the output.
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In v1.6.2.2~6^2~4 (Documentation: minor grammatical fixes
and rewording in git-bundle.txt, 2009-03-22), backslashes were
introduced before ~ to avoid introducing unintentional
superscripts. In one paragraph there is only one ~, though,
making that not a candidate for quoting, and asciidoc 8.5.8
passes the backslash through so the man page says "\~10..master".
Maybe there is an asciidoc behavior change involved.
In any case, we should replace tildes with a {tilde} entity which
means the same thing regardless of where it is found.
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Cc: David J. Mellor <dmellor@whistlingcat.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Due to some unpleasant interaction between the `quote', 'italics',
and `monospace` rules, a certain paragraph ends up rendered like so:
‘short` is a character for the short option
(e.g. <tt>'e\’</tt> for <tt>-e</tt>, use <tt>0</tt> to omit),
Use the {apostrophe} to avoid this.
While at it, escape "->" strings: they are meant as a literal
two-character C operator, not a right-pointing arrow.
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For some reason, various manual pages have an asterisk escaped
with \ in the synopsis. Since there is no other asterisk to pair it
with, Asciidoc does not consider this asterisk escapable, so it passes
the backslash through.
Each page either uses [verse] or has only one asterisk, so it
is safe to drop the backslashes (checked with asciidoc 8.5.2).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An asterisk in "Documentation/*.txt" quoted with \ to avoid bold text
is being output as \* because asciidoc does not consider it a
candidate for escaping (there is no matching * to pair it with).
So the manual looks like it is saying that one should write
"Documentation/\*.txt" in the .gitignore file.
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Intended output:
git rm Documentation/\*.txt
Removes all *.txt files from the index that are under
the Documentation directory and any of its
subdirectories.
Note that the asterisk * is quoted from the shell in
this example; this lets git, and not the shell, expand
the pathnames of files and subdirectories under the
Documentation/ directory.
Without this change, there are too many backslashes output.
Tested with asciidoc 8.5.2.
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Cc: Carl Worth <cworth@cworth.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without an indication to the contrary, Asciidoc puts 'quoted
text' in italics, making the output look like this:
git grep time_t -- *.[ch]
Looks for time_t in all tracked .c and .h
files in the working directory and its subdirectories.
git grep -e '#define\' --and \( -e MAX_PATH -e PATH_MAX \)
Looks for a line that has #define and either MAX_PATH or
PATH_MAX.
In the first example, the *.[ch] argument needs to be protected from
the shell, or else it will only match files in the current directory.
The second example has a stray backslash.
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Cc: Mark Lodato <lodatom@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The intended text looks like this:
· Adds content from all *.txt files under Documentation
directory and its subdirectories:
$ git add Documentation/\*.txt
Note that the asterisk * is quoted from the shell in this
example; this lets the command include the files from
subdirectories of Documentation/ directory.
The current asciidoc 8.5.2 output has a backslash before _every_
asterisk, which is more confusing than it needs to be.
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Cc: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I am not sure why, but the regular expression "(?:\^\{\})" gets
rendered by asciidoc as "(?:\{})". The intent seems to be a regex
matching the literal string "^{}", so this rewrites the markup to
produce "(?:\^{})" as output.
Cc: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current output (with Asciidoc 8.5.2) seems a bit broken:
given two directories ‘d` and d2, there is a difference
between using git rm 'd*’ and ‘git rm 'd/\*\’`, as the
former will also remove all of directory d2.
In other words, the markup parses as
given two directories << d` and _d2_, there is a difference
between using _git rm 'd* >>_ and << git rm 'd/\*\ >> `.
I suspect there is an asciidoc bug involved (why is ' a candidate
closing-quote mark when it is preceded by a backslash?) but with
all the meanings of ` and ' involved I do not want to track it
down. Better to use unambiguous {asterisk} and {apostrophe}
entities.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The markup "'git log'\'s" produces a stray backslash in the
produced man page. Removing the backslash fixes it.
While at it, tweak the surrounding description for readability.
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/rfc-reset-doc:
Documentation/reset: move "undo permanently" example behind "make topic"
Documentation/reset: reorder examples to match description
Documentation/reset: promote 'examples' one section up
Documentation/reset: separate options by mode
Documentation/git-reset: reorder modes for soft-mixed-hard progression
asciidoc already takes care of including a doctype for most of the
HTML documentation, but the user manual which is processed with
docbook-xsl directly lacks one (at least with Debian docbook-xsl
1.75.2+dfsg-5). This makes it harder to automatically validate the
HTML.
Reported-by: 積丹尼 <jidanni@jidanni.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since v1.7.1.1~23^2 (merge: --log appends shortlog to message if
specified, 2010-05-11), the fmt-merge-msg backend supports custom text
to override the merge title "Merge <foo> into <bar>".
Expose this functionality for scripted callers. Example:
git fmt-merge-msg --log -m \
"$(printf '%s\n' \
"Merge branch 'api-cleanup' into feature" \
'' \
'This is to use a few functions refactored for this purpose.'
)" <.git/FETCH_HEAD
Cc: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While show-branch --independent does not support more than MAX_REVS
revs, git internally supports more with a different algorithm.
Expose that functionality as "git merge-base --independent".
This should help scripts to catch up with builtin merge in supporting
dodecapus.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While show-branch --merge-base does not support more than MAX_REVS
revs, git supports more with a different algorithm
(v1.6.0-rc0~51^2~13, Introduce get_octopus_merge_bases() in commit.c,
2008-06-27). Expose that functionality.
This should help scripts to catch up with builtin merge in supporting
dodecapus.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For example, a person reading the merge-base man page might wonder
about the fastest way to check if one commit is an ancestor of
another (which would require rev-list).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jl/submodule-ignore-diff:
Add tests for the diff.ignoreSubmodules config option
Add the 'diff.ignoreSubmodules' config setting
Submodules: Use "ignore" settings from .gitmodules too for diff and status
Submodules: Add the new "ignore" config option for diff and status
Conflicts:
diff.c
* tc/checkout-B:
builtin/checkout: handle -B from detached HEAD correctly
builtin/checkout: learn -B
builtin/checkout: reword hint for -b
add tests for checkout -b
Add userdiff patterns for C#. This code is an improved version of
code by Adam Petaccia from 21 June 2009 mail to the list.
Signed-off-by: Petr Onderka <gsvick@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cherry-pick was written (v0.99.6~63, 2005-08-27), “git commit”
was quiet, and the output from cherry-pick provided useful information
about the progress of a rebase.
Now next to the output from “git commit”, the cherry-pick notification
is so much noise (except for the name of the picked commit).
$ git cherry-pick ..topic
Finished cherry-pick of 499088b.
[detached HEAD 17e1ff2] Move glob module to libdpkg
Author: Guillem Jover <guillem@debian.org>
8 files changed, 12 insertions(+), 9 deletions(-)
rename {src => lib/dpkg}/glob.c (98%)
rename {src => lib/dpkg}/glob.h (93%)
Finished cherry-pick of ae947e1.
[detached HEAD 058caa3] libdpkg: Add missing symbols to Versions script
Author: Guillem Jover <guillem@debian.org>
1 files changed, 2 insertions(+), 0 deletions(-)
$
The noise is especially troublesome when sifting through the output of
a rebase or multiple cherry-pick that eventually failed.
With the commit subject, it is already not hard to figure out where
the commit came from. So drop the “Finished” message.
Cc: Christian Couder <chriscool@tuxfamily.org>
Cc: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally, if remote.<name>.tagopt was set, the --tags and option would
have no effect when given to git fetch. So if
tagopt="--no-tags"
git fetch --tags
would not actually fetch tags.
This patch changes this behavior to only follow what is written in the
config if there is no option passed by the command line.
Signed-off-by: Daniel Johnson <ComputerDruid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/rfc-reset-doc:
Documentation/reset: move "undo permanently" example behind "make topic"
Documentation/reset: reorder examples to match description
Documentation/reset: promote 'examples' one section up
Documentation/reset: separate options by mode
Documentation/git-reset: reorder modes for soft-mixed-hard progression
Some firewalls restrict HTTP connections based on the clients user agent. This
commit provides the user the ability to modify the user agent string via either
a new config option (http.useragent) or by an environment variable
(GIT_HTTP_USER_AGENT).
Relevant documentation is added to Documentation/config.txt.
Signed-off-by: Spencer E. Olson <olsonse@umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an error is encountered, it calls add_rejected_file() which either
- directly displays the error message and stops if in plumbing mode
(i.e. if show_all_errors is not initialized at 1)
- or stores it so that it will be displayed at the end with display_error_msgs(),
Storing the files by error type permits to have a list of files for
which there is the same error instead of having a serie of almost
identical errors.
As each bind_overlap error combines a file and an old file, a list cannot be
done, therefore, theses errors are not stored but directly displayed.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The typical usage pattern would be to run a test (or simply a compilation
command) at given points in history.
The shell command is ran (from the worktree root), and the rebase is
stopped when the command fails, to give the user an opportunity to fix
the problem before continuing with "git rebase --continue".
This needs a little rework of skip_unnecessary_picks, which wasn't robust
enough to deal with lines like
exec >"file name with many spaces"
in the todolist. The new version extracts command, sha1 and rest from
each line, but outputs the line itself verbatim to avoid changing the
whitespace layout.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
gitweb: clarify search results page when no matching commit found
Documentation: add a FILES section for show-ref
Makefile: add missing dependency on http.h
Makefile: add missing dependencies on url.h
Documentation/git-log: Clarify --full-diff
git-rebase: fix typo when parsing --force-rebase
imap-send: Fix sprintf usage
prune: allow --dry-run for -n and --verbose for -v
notes: allow --dry-run for -n and --verbose for -v
Document -B<n>[/<m>], -M<n> and -C<n> variants of -B, -M and -C
Documentation: cite git-am from git-apply
t7003: fix subdirectory-filter test
Allow "check-ref-format --branch" from subdirectory
check-ref-format: handle subcommands in separate functions
pretty-options.txt: match --format's documentation with implementation.
A peek at where the refs are kept might help understanding, even if,
as the DESCRIPTION section suggests, direct access is not part of the
public API.
Balance that out with a pointer to update-ref.
Suggested-by: Geoff Russell <geoffrey.russell@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current description gives the impression that "--full-diff" affects
"log -p" only.
Make it clearer that it affects all diff-based output types.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For consistency with other git commands, let git prune accept the long
options --dry-run and --verbose for the respective short ones -n and -v.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For consistency with other git commands, let the prune subcommand of
git notes accept the long options --dry-run and --verbose for the
respective short ones -n and -v.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These options take an optional argument, but this optional argument was
not documented.
Original patch by Matthieu Moy, but documentation for -B mostly copied
from the explanations of Junio C Hamano.
While we're there, fix a typo in a comment in diffcore.h.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Users reading git-apply documentation may also be interested in git-am,
especially after receiving an email created with git-format-patch. The
documentation for git-am already references git-apply. Add the reverse.
Signed-off-by: Brad King <brad.king@kitware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have a lot of submodules checked out, the time penalty to check
for dirty submodules can easily imply a multiplication of the total time
by the factor 20. This makes the difference between almost instantaneous
(< 2 seconds) and unbearably slow (> 50 seconds) here, since the disk
caches are constantly overloaded.
To this end, the submodule.*.ignore config option was introduced, but it
is per-submodule.
This commit introduces a global config setting to set a default
(porcelain) value for the --ignore-submodules option, keeping the
default at 'none'. It can be overridden by the submodule.*.ignore
setting and by the --ignore-submodules option.
Incidentally, this commit fixes an issue with the overriding logic:
multiple --ignore-submodules options would not clear the previously
set flags.
While at it, fix a typo in the documentation for submodule.*.ignore.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The .gitmodules file is parsed for "submodule.<name>.ignore" entries
before looking for them in .git/config. Thus settings found in .git/config
will override those from .gitmodules, thereby allowing the local developer
to ignore settings given by the remote side while also letting upstream
set defaults for those users who don't have special needs.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new "ignore" config option controls the default behavior for "git
status" and the diff family. It specifies under what circumstances they
consider submodules as modified and can be set separately for each
submodule.
The command line option "--ignore-submodules=" has been extended to accept
the new parameter "none" for both status and diff.
Users that chose submodules to get rid of long work tree scanning times
might want to set the "dirty" option for those submodules. This brings
back the pre 1.7.0 behavior, where submodule work trees were never
scanned for modifications. By using "--ignore-submodules=none" on the
command line the status and diff commands can be told to do a full scan.
This option can be set to the following values (which have the same name
and meaning as for the "--ignore-submodules" option of status and diff):
"all": All changes to the submodule will be ignored.
"dirty": Only differences of the commit recorded in the superproject and
the submodules HEAD will be considered modifications, all changes
to the work tree of the submodule will be ignored. When using this
value, the submodule will not be scanned for work tree changes at
all, leading to a performance benefit on large submodules.
"untracked": Only untracked files in the submodules work tree are ignored,
a changed HEAD and/or modified files in the submodule will mark it
as modified.
"none" (which is the default): Either untracked or modified files in a
submodules work tree or a difference between the subdmodules HEAD
and the commit recorded in the superproject will make it show up
as changed. This value is added as a new parameter for the
"--ignore-submodules" option of the diff family and "git status"
so the user can override the settings in the configuration.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach "git merge-recursive" a --renormalize option to enable the
merge.renormalize configuration. The --no-renormalize option can
be used to override it in the negative.
So in the future, you might be able to, e.g.:
git checkout -m -Xrenormalize otherbranch
or
git revert -Xrenormalize otherpatch
or
git pull --rebase -Xrenormalize
The bad part: merge.renormalize is still not honored for most
commands. And it reveals lots of places that -X has not been plumbed
in (so we get "git merge -Xrenormalize" but not much else).
NEEDSWORK: tests
Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ll_merge() takes its options in a flag word, which has a few
advantages:
- options flags can be cheaply passed around in registers, while
an option struct passed by pointer cannot;
- callers can easily pass 0 without trouble for no options,
while an option struct passed by value would not allow that.
The downside is that code to populate and access the flag word can be
somewhat opaque. Mitigate that with a few macros.
Cc: Avery Pennarun <apenwarr@gmail.com>
Cc: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cc: Junio C Hamano <gitster@pobox.com>
Cc: Avery Pennarun <apenwarr@gmail.com>
Cc: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-rebase calls out to merge strategies, but did not support merge
strategy options so far. Add this, in the same style used in
git-merge.
Sadly we have to do the full quoting/eval dance here, since
merge-recursive supports the --subtree=<path> option which potentially
contains whitespace.
This patch does not cover git rebase -i, which does not call any merge
strategy directly except in --preserve-merges, and even then only for
merges.
[jc: with a trivial fix-up for 'expr']
Signed-off-by: Mike Lundy <mike@fluffypenguin.org>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current description in the pull man page does not say much more
than that “git pull” is fetch + merge. Though that is all a person
needs to know in the end, it would be useful to summarize a bit about
what those commands do for new readers.
Most of this description is taken from the “git merge” docs.
Now that we explain how to back out of a failed merge (reset --merge),
we can tone down the warning against that a bit.
Except, as Thomas noticed, there’s a risk with that because people
might read this version of the manpage online and then conclude that
it is safe to try a merge with uncommitted changes, only to find that
their “git reset” doesn't support --merge yet. Or worse, verify that
their git-reset has --merge by a quick test (1b5b465 is in 1.6.2) but
then find that it does not help with backing out of a merge (e11d7b5
is only in 1.7.0!). So keep the warning.
With clarifications from Ævar, Thomas, and Junio.
Noticed-by: Geoff Russell <geoffrey.russell@gmail.com>
Cc: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Cc: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The flags --start, --stop, and --restart can be used without the "--".
Document this feature.
Signed-off-by: Jared Hance <jaredhance@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach git-ls-files a new option --debug that just tacks all available
data from the cache onto each file's line.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
test-lib: Remove 3 year old no-op --no-python option
test-lib: Ignore --quiet under a TAP harness
Documentation/rev-parse: quoting is required with --parseopt
Documentation: reporting bugs
Fix git rebase --continue to work with touched files
Document ls-files -t as semi-obsolete.
When calling rev-parse --parseopt, as in the (now fixed) documented
example
eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
the outermost quoting is required, as otherwise all runs of arbitrary
whitespace inside the resulting 'set -- ...' call would be collapsed
into a single space.
This was exposed as a result of our new use of cat <<\EOF since
47e9cd2 (parseopt: wrap rev-parse --parseopt usage for eval
consumption, 2010-06-12), but has always been a problem when handling
arguments containing e.g. newlines.
Point this out in the documentation, and in particular correct the
example that did not have the quotes.
Noticed-by: Joshua Jensen <jjensen@workspacewhiz.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a new option 'svn.pathnameencoding' that instructs git svn to
recode pathnames to a given encoding. It can be used by windows users
and by those who work in non-utf8 locales to avoid corrupted file names
with non-ascii characters.
[rp: renamed the option and added manpage documentation]
Signed-off-by: Dmitry Statyvka <dstatyvka@tmsoft-ltd.kiev.ua>
Signed-off-by: Robert Pollak <robert.pollak@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
The behavior of "git ls-files -t" is very misleading (see
http://thread.gmane.org/gmane.comp.version-control.git/126516 and
http://thread.gmane.org/gmane.comp.version-control.git/144394/focus=144397
for examples of mislead users) and badly documented, hence we point the
users to superior alternatives.
The feature is marked as "semi-obsolete" but not "scheduled for removal"
since it's a plumbing command, scripts might use it, and Git testsuite
already uses it to test the state of the index.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the SubmittingPatches recommendations to mention the 50
character soft limit on patch subject lines. 50 characters is the soft
limit mentioned in git-commit(1) and gittutorial(7), it's also the
point at which Gitweb, GitHub and various other Git front ends start
abbreviating the commit message.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The wording of the Signed-off-by rules could be read as stating that
S-O-B should only be added when the submitter considered the patch
ready for inclusion in git.git.
We also want Signed-off-by to be used for e.g. RFC patches, in case
someone wants to dig an old patch out of the archive and improve
it. Change the wording to recommend a Signed-off-by for all submitted
patches.
The problem with the wording came up in the "[PATCH/RFC] Hacky version
of a glob() driven config include" thread[1]. Bert Wesarg suggested[2]
that it be removed to avoid confusion, which this change implements.
1. <1273180440-8641-1-git-send-email-avarab@gmail.com>
2. <AANLkTimziTKL13VKIOcaS1TX1F_xvTVjH8Q398Yx36Us@mail.gmail.com>
Suggested-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mention the effects of the receive.deny* family of options for the
"remote rejected" case. While there, also split up the explanation
into an easier-to-parse list format.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option was introduced by 747ca24 (receive-pack:
receive.denyDeleteCurrent, 2009-02-08) but never documented.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.6:
request-pull.txt: Document -p option
Check size of path buffer before writing into it
rev-parse: fix --parse-opt --keep-dashdash --stop-at-non-option
* maint-1.6.5:
request-pull.txt: Document -p option
Check size of path buffer before writing into it
rev-parse: fix --parse-opt --keep-dashdash --stop-at-non-option
With the -e/--exclude option for git-clean, a user can specify files
that they haven't yet told git about, but either need for a short amount
of time or plan to tell git about them later. This allows one to still
use git-clean while these files are around without losing data.
Signed-off-by: Jared Hance <jaredhance@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option adds symmetry with fast-import, enabling it to also work with
complete trees instead of just incremental changes. It works by issuing a
'deleteall' directive with each commit and then listing the full set of
files that make up that commit, rather than just showing the list of files
that have changed since the (first) parent commit. Note that this
functionality is automatically turned on when using --import-marks together
with path limiting in order to avoid dropping important but unchanged
files.
This functionality is desired when using hand-written filters along with
'fast-export | some-filter | fast-import' as it can be easier to write
<some-filter> in terms of complete trees than incremental changes.
We could avoid the need to add this option by simply always turning it on.
While the end result would be identical, it would slow things down slightly
by printing many more filenames per commit which goes somewhat against the
'fast' in 'fast-export'.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All the git add options were listed in the synopsis until the
--ignore-missing option was added. Change that so that the git add
documentation now has the complete listing.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git submodule add no longer implicitly adds with --force. Remove
references to the old functionality in the documentation.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To make the behavior of "git submodule add" more consistent with "git add"
ignored submodule paths should not be silently added when they match an
entry in a .gitignore file. To be able to override that default behavior
in the same way as we can do that for "git add", the new option "--force"
is introduced.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git mergetool' creates '*.orig' backup files in its
default configuration. Mention this in its documentation.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A previous commit moved the <paths> mode (undoes git-add) to the front
in the description, so make the examples follow the same order.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move the examples section upwards, before the discussion that gives
the gory details. Adjust the style of the heading accordingly.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove all but -q from the OPTIONS section, and instead explain the
options separated by usage mode, since they only apply to one each.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reorder the documetation so that the soft/mixed/hard modes are in this
order. This way they form a natural progression towards changing more
of the state.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mg/revision-doc:
Documentation: link to gitrevisions rather than git-rev-parse
Documentation: gitrevisions
Documentation: split off rev doc into include file
The url, path, and the update items in [submodule "foo"] stanzas
are nicely explained in the .gitmodules and ‘git submodule’
documentation. Point there from the config documentation.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is already excellent documentation for this facility in
git-submodule.1, but it is not so discoverable.
Relative paths in .gitmodules can be useful for serving the
same repository over multiple protocols, for example.
Thanks to Peter for pointing this out.
Cc: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you use this feature regularly you can now enable it by default. In
case the user wants to override this config on the commandline
--no-autosquash can be used to force disabling.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes it is useful to know if a file or directory will be ignored
before it is added to the work tree. An example is "git submodule add",
where it would be really nice to be able to fail with an appropriate
error message before the submodule is cloned and checked out.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Documentation: Spelling fix in protocol-capabilities.txt
checkout: accord documentation to what git does
t0005: work around strange $? in ksh when program terminated by a signal
This will reduce considerably the common confusion where people miss the
`--follow' option, and wonder why `-M'/`-C' is not working.
* Move the diff options include to after the log-specific flags, and add
a "Common diff options" subtitle before them. (These options apply
only when patches are shown, which is not a common use case among
newbies, so having them first is confusing.)
* Move the `--follow' description to the top of the listed options. The
options before that seem less important: `--full-diff' applies only
when patches are shown, `--source' and `--decorate' are less useful
with many common commit specifications.
* Clarify that `--follow' works only for a single path argument.
Signed-off-by: Eli Barzilay <eli@barzilay.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
backmerge a few more fixes to 1.7.1.X series
rev-parse: fix --parse-opt --keep-dashdash --stop-at-non-option
fix git branch -m in presence of cross devices
Conflicts:
RelNotes
builtin/rev-parse.c
Currently, whenever we need documentation for revisions and ranges, we
link to the git-rev-parse man page, i.e. a plumbing man page, which has
this along with the documentation of all rev-parse modes.
Link to the new gitrevisions man page instead in all cases except
- when the actual git-rev-parse command is referred to or
- in very technical context (git-send-pack).
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Create a new man page gitrevisions(7) which contains the revsions and
ranges documentation but not more. This uses (per include) the same bits
as the pertaining section of git-rev-parse(1).
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, the documentation for revisions and ranges sits in the
git-rev-parse man page, i.e. a plumbing man page, along with the
documentation of all rev-parse modes.
Split off the revisions and ranges section into an included file to
prepare for restructuring.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To simulate the svn cp command, it would be very useful to be
replace an arbitrary file in the current revision by an
arbitrary directory from a previous one. Modify the filemodify
command to allow that:
M 040000 <tree id> pathname
This would be most useful in combination with a facility to
print the commit ids for new revisions as they are written.
Cc: Shawn O. Pearce <spearce@spearce.org>
Cc: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change `git submodule add' to add the new submodule <path> with `git
add --force'.
I keep my /etc in .git with a .gitignore that contains just
"*". I.e. `git status' will ignore everything that isn't in the tree
already. When I do:
git submodule add <url> hlagh
git-submodule will get as far as checking out the remote repository
into hlagh, but it'll die right afterwards when it fails to add the
new path:
The following paths are ignored by one of your .gitignore files:
hlagh
Use -f if you really want to add them.
fatal: no files added
Failed to add submodule 'hlagh'
Currently there's no way to add a submodule in this situation other
than to remove the ignored path from the .gitignore while I'm at it.
That's silly, when you run `git submodule add' you're explicitly
saying that you want to add something *new* to the repository. Instead
it should just add the path with `git add --force'.
Initially I implemented this by adding new -f and --force options to
`git submodule add'. But if the --force option isn't supplied it'll
get as far as cloning `hlagh', but won't add it.
So the first thing the user has to do is to remove `hlagh' and then
try again with the --force option.
That sucks, it should just add the path to begin with. I can't think
of any usecase where you've gone through the trouble of typing out
`git submodule add ..', but wish to be overriden by a `gitignore'. The
submodule semantics should be more like `git init', not `git add'.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
dea4562 (rerere forget path: forget recorded resolution, 2009-12-25)
introduced the forget subcommand for rerere.
Document it.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, merging across changes in line ending normalization is
painful since files containing CRLF will conflict with normalized files,
even if the only difference between the two versions is the line
endings. Additionally, any "real" merge conflicts that exist are
obscured because every line in the file has a conflict.
Assume you start out with a repo that has a lot of text files with CRLF
checked in (A):
o---C
/ \
A---B---D
B: Add "* text=auto" to .gitattributes and normalize all files to
LF-only
C: Modify some of the text files
D: Try to merge C
You will get a ridiculous number of LF/CRLF conflicts when trying to
merge C into D, since the repository contents for C are "wrong" wrt the
new .gitattributes file.
Fix ll-merge so that the "base", "theirs" and "ours" stages are passed
through convert_to_worktree() and convert_to_git() before a three-way
merge. This ensures that all three stages are normalized in the same
way, removing from consideration differences that are only due to
normalization.
This feature is optional for now since it changes a low-level mechanism
and is not necessary for the majority of users. The "merge.renormalize"
config variable enables it.
Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This advertises the existence of the 'pre-auto-gc' hook and adds a cross
reference to where the hook is documented.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ar/decorate-color:
Add test for correct coloring of git log --decoration
Allow customizable commit decorations colors
log --decorate: Colorize commit decorations
log-tree.c: Use struct name_decoration's type for classifying decoration
commit.h: add 'type' to struct name_decoration
* cc/cherry-pick-stdin:
revert: do not rebuild argv on heap
revert: accept arbitrary rev-list options
t3508 (cherry-pick): futureproof against unmerged files
* jl/status-ignore-submodules:
Add the option "--ignore-submodules" to "git status"
git submodule: ignore dirty submodules for summary and status
Conflicts:
builtin/commit.c
t/t7508-status.sh
wt-status.c
wt-status.h
* jp/string-list-api-cleanup:
string_list: Fix argument order for string_list_append
string_list: Fix argument order for string_list_lookup
string_list: Fix argument order for string_list_insert_at_index
string_list: Fix argument order for string_list_insert
string_list: Fix argument order for for_each_string_list
string_list: Fix argument order for print_string_list
* jl/maint-diff-ignore-submodules:
t4027,4041: Use test -s to test for an empty file
Add optional parameters to the diff option "--ignore-submodules"
git diff: rename test that had a conflicting name
* commit 'v1.7.2-rc0~6^2':
DWIM 'git show -5' to 'git show --do-walk -5'
Documentation/SubmittingPatches: Fix typo in GMail section
Documentation/config: describe status.submodulesummary
This commit fixes one test in t3508 by making "cherry-pick -<num>"
walk the history.
A test update from Elijah Newren is squashed as an evil merge.
