"git diff" learned a variant of the "--patience" algorithm, to
which the user can specify which 'unique' line to be used as
anchoring points.
* jt/diff-anchored-patience:
diff: support anchoring line(s)
@{-N} in "git checkout @{-N}" may refer to a detached HEAD state,
but the documentation was not clear about it, which has been fixed.
* ks/doc-checkout-previous:
Doc/checkout: checking out using @{-N} can lead to detached state
"git send-email" tries to see if the sendmail program is available
in /usr/lib and /usr/sbin; extend the list of locations to be
checked to also include directories on $PATH.
* fk/sendmail-from-path:
git-send-email: honor $PATH for sendmail binary
The tagnames "git log --decorate" uses to annotate the commits can
now be limited to subset of available refs with the two additional
options, --decorate-refs[-exclude]=<pattern>.
* ra/decorate-limit-refs:
log: add option to choose which refs to decorate
The ssh-variant 'simple' introduced earlier broke existing
installations by not passing --port/-4/-6 and not diagnosing an
attempt to pass these as an error. Instead, default to
automatically detect how compatible the GIT_SSH/GIT_SSH_COMMAND is
to OpenSSH convention and then error out an invocation to make it
easier to diagnose connection errors.
* jn/ssh-wrappers:
connect: correct style of C-style comment
ssh: 'simple' variant does not support --port
ssh: 'simple' variant does not support -4/-6
ssh: 'auto' variant to select between 'ssh' and 'simple'
connect: split ssh option computation to its own function
connect: split ssh command line options into separate function
connect: split git:// setup into a separate function
connect: move no_fork fallback to git_tcp_connect
ssh test: make copy_ssh_wrapper_as clean up after itself
A new mechanism to upgrade the wire protocol in place is proposed
and demonstrated that it works with the older versions of Git
without harming them.
* bw/protocol-v1:
Documentation: document Extra Parameters
ssh: introduce a 'simple' ssh variant
i5700: add interop test for protocol transition
http: tell server that the client understands v1
connect: tell server that the client understands v1
connect: teach client to recognize v1 server response
upload-pack, receive-pack: introduce protocol version 1
daemon: recognize hidden request arguments
protocol: introduce protocol extension mechanisms
pkt-line: add packet_write function
connect: in ref advertisement, shallows are last
"git config --expiry-date gc.reflogexpire" can read "2.weeks" from
the configuration and report it as a timestamp, just like "--int"
would read "1k" and report 1024, to help consumption by scripts.
* hm/config-parse-expiry-date:
config: add --expiry-date
"git branch --set-upstream" has been deprecated and (sort of)
removed, as "--set-upstream-to" is the preferred one these days.
The documentation still had "--set-upstream" listed on its
synopsys section, which has been corrected.
* tz/branch-doc-remove-set-upstream:
branch doc: remove --set-upstream from synopsis
"git checkout --recursive" may overwrite and rewind the history of
the branch that happens to be checked out in submodule
repositories, which might not be desirable. Detach the HEAD but
still allow the recursive checkout to succeed in such a case.
* sb/submodule-recursive-checkout-detach-head:
Documentation/checkout: clarify submodule HEADs to be detached
recursive submodules: detach HEAD from new state
Clarify and enhance documentation for "merge-base --fork-point", as
it was clear what it computed but not why/what for.
* jc/merge-base-fork-point-doc:
merge-base --fork-point doc: clarify the example and failure modes
The SubmittingPatches document has been converted to produce an
HTML version via AsciiDoc/Asciidoctor.
* bc/submitting-patches-in-asciidoc:
Documentation: convert SubmittingPatches to AsciiDoc
Documentation: enable compat-mode for Asciidoctor
"git branch --list" learned to show its output through the pager by
default when the output is going to a terminal, which is controlled
by the pager.branch configuration variable. This is similar to a
recent change to "git tag --list".
* ma/branch-list-paginate:
branch: change default of `pager.branch` to "on"
branch: respect `pager.branch` in list-mode only
t7006: add tests for how git branch paginates
@{-N} is a syntax for the N-th last "checkout" and not the N-th
last "branch". Therefore, in some cases using `git checkout @{-$N}`
DOES lead to a "detached HEAD" state. This can also be ensured by
the commit message of 75d6e552a (Documentation: @{-N} can refer to
a commit, 2014-01-19) which clearly specifies how @{-N} can be used
to refer not only to a branch but also to a commit.
Correct the misleading sentence which states that @{-N} doesn't
detach HEAD.
Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach diff a new algorithm, one that attempts to prevent user-specified
lines from appearing as a deletion or addition in the end result. The
end user can use this by specifying "--anchored=<text>" one or more
times when using Git commands like "diff" and "show".
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This extends git-send-email to also consider sendmail binaries in $PATH
after checking the (fixed) list of /usr/sbin and /usr/lib, and before
falling back to localhost.
Signed-off-by: Florian Klink <flokli@flokli.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you come to the documentation thinking "I do not want Git
to take any locks for my background processes", then you may
easily run across "--no-optional-locks" in git.txt.
But it's quite reasonable to hit a specific instance of the
problem: you have "git status" running in the background,
and you notice that it causes lock contention with other
processes. So you look in git-status.txt to see if there is
a way to disable it, but there's no mention of the flag.
Let's add a short note mentioning that status does indeed
touch the index (and why), with a pointer to the global
option. That can point users in the right direction and help
them make a more informed decision about what they're
disabling.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git add --renormalize ." is a new and safer way to record the fact
that you are correcting the end-of-line convention and other
"convert_to_git()" glitches in the in-repository data.
* tb/add-renormalize:
add: introduce "--renormalize"
Teach "sendemail.tocmd" to places that know about "sendemail.to",
like documentation and shell completion (in contrib/).
* rv/sendemail-tocmd-in-config-and-completion:
completion: add git config sendemail.tocmd
Documentation/config: add sendemail.tocmd to list preceding "See git-send-email(1)"
Clarify and enhance documentation for "merge-base --fork-point", as
it was clear what it computed but not why/what for.
* jc/merge-base-fork-point-doc:
merge-base --fork-point doc: clarify the example and failure modes
The "diff" family of commands learned to ignore differences in
carriage return at the end of line.
* jc/ignore-cr-at-eol:
diff: --ignore-cr-at-eol
xdiff: reassign xpparm_t.flags bits
Doc update around use of "format-patch --subject-prefix" etc.
* ad/submitting-patches-title-decoration:
doc/SubmittingPatches: correct subject guidance
The text meant to say that receive-pack runs these hooks, and only
because receive-pack is not a command the end users use every day
(ever), as an explanation also meantioned that it is run in response
to 'git push', which is an end-user facing command readers hopefully
know about.
This unfortunately gave an incorrect impression that 'git push'
always result in the hook to run. If the refs push wanted to update
all already had the desired value, these hooks are not run.
Explicitly mention "... and updates reference(s)" as a precondition
to avoid this confusion.
Helped-by: Christoph Michelbach <michelbach94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although `git stash save` was deprecated recently, some parts of the
documentation still refer to it instead of `push`.
Signed-off-by: Phil Hord <phil.hord@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When `log --decorate` is used, git will decorate commits with all
available refs. While in most cases this may give the desired effect,
under some conditions it can lead to excessively verbose output.
Introduce two command line options, `--decorate-refs=<pattern>` and
`--decorate-refs-exclude=<pattern>` to allow the user to select which
refs are used in decoration.
When "--decorate-refs=<pattern>" is given, only the refs that match the
pattern are used in decoration. The refs that match the pattern when
"--decorate-refs-exclude=<pattern>" is given, are never used in
decoration.
These options follow the same convention for mixing negative and
positive patterns across the system, assuming that the inclusive default
is to match all refs available.
(1) if there is no positive pattern given, pretend as if an
inclusive default positive pattern was given;
(2) for each candidate, reject it if it matches no positive
pattern, or if it matches any one of the negative patterns.
The rules for what is considered a match are slightly different from the
rules used elsewhere.
Commands like `log --glob` assume a trailing '/*' when glob chars are
not present in the pattern. This makes it difficult to specify a single
ref. On the other hand, commands like `describe --match --all` allow
specifying exact refs, but do not have the convenience of allowing
"shorthand refs" like 'refs/heads' or 'heads' to refer to
'refs/heads/*'.
The commands introduced in this patch consider a match if:
(a) the pattern contains globs chars,
and regular pattern matching returns a match.
(b) the pattern does not contain glob chars,
and ref '<pattern>' exists, or if ref exists under '<pattern>/'
This allows both behaviours (allowing single refs and shorthand refs)
yet remaining compatible with existent commands.
Helped-by: Kevin Daudt <me@ikke.info>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, 'git notes prune' in man page and usage message
incorrectly lists options as '[-n | -v]', rather than '[-n] [-v]'.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add mention of git prune's "--progress" option to the SYNOPSIS and
DESCRIPTION sections of the man page, and to the usage message of "git
prune" itself.
While we're here, move the explanation of "--" toward the end of the
DESCRIPTION section, where it belongs.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While the "git reflog" man page supports both "--dry-run" and "-n" for
a dry run, the man page mentions only the former, not the latter.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Doc update around use of "format-patch --subject-prefix" etc.
* ad/submitting-patches-title-decoration:
doc/SubmittingPatches: correct subject guidance
