Move all rebase.* configuration variables to a separate file in order to
remove duplicates, and include it in config.txt and git-rebase.txt. The
new descriptions are mostly taken from config.txt as they are more
verbose.
Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a helper print_sha1_ellipsis() that pays attention to the
GIT_PRINT_SHA1_ELLIPSIS environment variable, and prepare the tests to
unconditionally set it for the test pieces that will be broken once the code
stops showing the extra dots by default.
The removal of these dots is merely a plan at this step and has not happened
yet but soon will.
Document GIT_PRINT_SHA1_ELLIPSIS.
Signed-off-by: Ann T Ropea <bedhanger@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no need to use full 40-hex to identify the object names like
the examples hint at by omitting the tail part of an object name as if
that has to be spelled out but the example omits them only for brevity.
Give examples using abbreviated object names without ellipses just like
how people do in real life.
Signed-off-by: Ann T Ropea <bedhanger@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the documentation of diff-tree, it is stated that the -l option
"prevents rename/copy detection from running if the number of
rename/copy targets exceeds the specified number". The documentation
does not mention any special handling for the number 0, but the
implementation before commit 9f7e4bfa3b ("diff: remove silent clamp of
renameLimit", 2017-11-13) treated 0 as a special value indicating that
the rename limit is to be a very large number instead.
The commit 9f7e4bfa3b changed that behavior, treating 0 as 0. Revert
this behavior to what it was previously. This allows existing scripts
and tools that use "-l0" to continue working. The alternative (to have
"-l0" suppress rename detection) is probably much less useful, since
users can just refrain from specifying -M and/or -C to have the same
effect.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git grep -W", "git diff -W" and their friends learned a heuristic
to extend a pre-context beyond the line that matches the "function
pattern" (aka "diff.*.xfuncname") to include a comment block, if
exists, that immediately precedes it.
* rs/include-comments-before-the-function-header:
grep: show non-empty lines before functions with -W
grep: update boundary variable for pre-context
t7810: improve check of -W with user-defined function lines
xdiff: show non-empty lines before functions with -W
xdiff: factor out is_func_rec()
t4051: add test for comments preceding function lines
"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
"git branch" and "git checkout -b" are now forbidden from creating
a branch whose name is "HEAD".
* jc/branch-name-sanity:
builtin/branch: remove redundant check for HEAD
branch: correctly reject refs/heads/{-dash,HEAD}
branch: split validate_new_branchname() into two
branch: streamline "attr_only" handling in validate_new_branchname()
There was a recent semantic mismerge in the codepath to write out a
section of a configuration section, which has been corrected.
* rs/config-write-section-fix:
config: flip return value of write_section()
Commit 78a6766802 ("Integrate hash algorithm support with repo setup",
2017-11-12) added a 'const struct git_hash_algo *hash_algo' field to the
repository structure, without modifying the initializer of the 'the_repo'
variable. This does not actually introduce a bug, since the '0' initializer
for the 'ignore_env:1' bit-field is interpreted as a NULL pointer (hence
the warning), and the final field (now with no initializer) receives a
default '0'.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
@{-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>
Contrary to the documentation, "git pull -4/-6 other-args" did not
ask the underlying "git fetch" to go over IPv4/IPv6, which has been
corrected.
* sw/pull-ipv46-passthru:
pull: pass -4/-6 option to 'git fetch'
Mentions of "git-rebase" and "git-am" (dashed form) still remained
in end-user visible strings emitted by the "git rebase" command;
they have been corrected.
* ks/rebase-no-git-foo:
git-rebase: clean up dashed-usages in messages
There was a recent semantic mismerge in the codepath to write out a
section of a configuration section, which has been corrected.
* rs/config-write-section-fix:
config: flip return value of write_section()
When "git rebase" prepared an mailbox of changes and fed it to "git
am" to replay them, it was confused when a stray "From " happened
to be in the log message of one of the replayed changes. This has
been corrected.
* ew/rebase-mboxrd:
rebase: use mboxrd format to avoid split errors
"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"
Command line completion (in contrib/) has been taught about the
"--copy" option of "git branch".
* tz/complete-branch-copy:
completion: add '--copy' option to 'git branch'
"git apply --inaccurate-eof" when used with "--ignore-space-change"
triggered an internal sanity check, which has been fixed.
* rs/apply-inaccurate-eof-with-incomplete-line:
apply: update line lengths for --inaccurate-eof
The sequencer machinery (used by "git cherry-pick A..B", and "git
rebase -i", among other things) would have lost a commit if stopped
due to an unlockable index file, which has been fixed.
* pw/sequencer-recover-from-unlockable-index:
sequencer: reschedule pick if index can't be locked
The three-way merge performed by "git cherry-pick" was confused
when a new submodule was added in the meantime, which has been
fixed (or "papered over").
* sb/test-cherry-pick-submodule-getting-in-a-way:
merge-recursive: handle addition of submodule on our side of history
t/3512: demonstrate unrelated submodule/file conflict as cherry-pick failure
"git notes" sent its error message to its standard output stream,
which was corrected.
* tz/notes-error-to-stderr:
notes: send "Automatic notes merge failed" messages to stderr
A few scripts (both in production and tests) incorrectly redirected
their error output. These have been corrected.
* tz/redirect-fix:
rebase: fix stderr redirect in apply_autostash()
t/lib-gpg: fix gpgconf stderr redirect to /dev/null
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
Leak fixes.
* ma/bisect-leakfix:
bisect: fix memory leak when returning best element
bisect: fix off-by-one error in `best_bisection_sorted()`
bisect: fix memory leak in `find_bisection()`
bisect: change calling-convention of `find_bisection()`
A fix for an ancient bug in "git apply --ignore-space-change" codepath.
* rs/apply-fuzzy-match-fix:
apply: avoid out-of-bounds access in fuzzy_matchlines()
Doc update around use of "format-patch --subject-prefix" etc.
* ad/submitting-patches-title-decoration:
doc/SubmittingPatches: correct subject guidance
Error checking in "git imap-send" for empty response has been
improved.
* rs/imap-send-next-arg-fix:
imap-send: handle missing response codes gracefully
imap-send: handle NULL return of next_arg()
test_cmp_rev is a useful function that's used in quite a few test
scripts. It is however not documented in t/README. Document it.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We generally no longer include copyright notices in new test scripts.
However t/README still mentions it as something to include at the top of
every new script.
Remove that mention as it's outdated.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Trace key normalization is not used, not strictly necessary,
complicates the code and would negatively affect compilation speed if
moved to header.
New trace_default_key key or existing separate marco could be used
instead of passing NULL as a key.
Signed-off-by: Gennady Kupava <gkupava@bloomberg.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a text file had been commited with CRLF and the file is commited
again, the CRLF are kept if .gitattributs has "text=auto".
This is done by analyzing the content of the blob stored in the index:
If a '\r' is found, Git assumes that the blob was commited with CRLF.
The simple search for a '\r' does not always work as expected:
A file is encoded in UTF-16 with CRLF and commited. Git treats it as binary.
Now the content is converted into UTF-8. At the next commit Git treats the
file as text, the CRLF should be converted into LF, but isn't.
Replace has_cr_in_index() with has_crlf_in_index(). When no '\r' is found,
0 is returned directly, this is the most common case.
If a '\r' is found, the content is analyzed more deeply.
Reported-By: Ashish Negi <ashishnegi33@gmail.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug,
2014-05-01), it was observed that removing files could be problematic on
case insensitive file systems, because we could end up removing files
that differed in case only rather than deleting the intended file --
something that happened when files were renamed on one branch in a way
that differed only in case. To avoid that problem, that commit added
logic to avoid removing files other than the one intended, rejecting the
removal if the files differed only in case.
Unfortunately, the logic it used didn't fully implement that condition as
stated above; instead it merely checked that a case-insensitive lookup of
the file that was requested resulted in finding a file in the index at
stage 0, not that the file found in the index actually differed in case.
Alternatively, one could view the implementation as making an implicit
assumption that the file we actually wanted to remove would never appear
in the index with a stage of 0, and thus that if we found a file with our
lookup, that it had to be a different file (but different in case only).
The net result of this implementation is that it can ignore more requests
than it should, leaving a file around in the working copy that should
have been removed. Make sure that the file found in the index actually
differs in case before silently ignoring the request to remove the file.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently 'git worktree add <path> <branch>', errors out when 'branch'
is not a local branch. It has no additional dwim'ing features that one
might expect.
Make it behave more like 'git checkout <branch>' when the branch doesn't
exist locally, but a remote tracking branch uniquely matches the desired
branch name, i.e. create a new branch from the remote tracking branch
and set the upstream to the remote tracking branch.
As 'git worktree add' currently just dies in this situation, there are
no backwards compatibility worries when introducing this feature.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently 'git worktree add' sets up tracking branches if '<branch>' is
a remote tracking branch, and doesn't set them up otherwise, as is the
default for 'git branch'.
This may or may not be what the user wants. Allow overriding this
behaviour with a --[no-]track flag that gets passed through to 'git
branch'.
We already respect branch.autoSetupMerge, as 'git worktree' just calls
'git branch' internally.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently 'git worktree add' is documented to take an optional <branch>
argument, which is checked out in the new worktree. However it is more
generally possible to use a commit-ish as the optional argument, and
check that out into the new worktree.
Document that this is a possibility, as new users of git worktree add
might find it helpful.
Reported-by: Randall S. Becker <rsbecker@nexbridge.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
