"git diff" and friends learned "--compact-summary" that shows the
information usually given with the "--summary" option on the same
line as the diffstat output of the "--stat" option (which saves
vertical space and keeps info on a single path at the same place).
* nd/diff-stat-with-summary:
diff: add --compact-summary
diff.c: refactor pprint_rename() to use strbuf
Writing out the index file when the only thing that changed in it
is the untracked cache information is often wasteful, and this has
been optimized out.
* bp/untracked-cache-noflush:
untracked cache: use git_env_bool() not getenv() for customization
dir.c: don't flag the index as dirty for changes to the untracked cache
"git status" can spend a lot of cycles to compute the relation
between the current branch and its upstream, which can now be
disabled with "--no-ahead-behind" option.
* jh/status-no-ahead-behind:
status: support --no-ahead-behind in long format
status: update short status to respect --no-ahead-behind
status: add --[no-]ahead-behind to status and commit for V2 format.
stat_tracking_info: return +1 when branches not equal
Since Git 1.7.9, "git merge" defaulted to --no-ff (i.e. even when
the side branch being merged is a descendant of the current commit,
create a merge commit instead of fast-forwarding) when merging a
tag object. This was appropriate default for integrators who pull
signed tags from their downstream contributors, but caused an
unnecessary merges when used by downstream contributors who
habitually "catch up" their topic branches with tagged releases
from the upstream. Update "git merge" to default to --no-ff only
when merging a tag object that does *not* sit at its usual place in
refs/tags/ hierarchy, and allow fast-forwarding otherwise, to
mitigate the problem.
* jc/allow-ff-merging-kept-tags:
merge: allow fast-forward when merging a tracked tag
The new "--show-current-patch" option gives an end-user facing way
to get the diff being applied when "git rebase" (and "git am")
stops with a conflict.
* nd/rebase-show-current-patch:
rebase: introduce and use pseudo-ref REBASE_HEAD
rebase: add --show-current-patch
am: add --show-current-patch
Clarify how configured fetch refspecs interact with the "--prune"
option of "git fetch", and also add a handy short-hand for getting
rid of stale tags that are locally held.
* ab/fetch-prune:
fetch: make the --prune-tags work with <url>
fetch: add a --prune-tags option and fetch.pruneTags config
fetch tests: add scaffolding for the new fetch.pruneTags
git-fetch & config doc: link to the new PRUNING section
git remote doc: correct dangerous lies about what prune does
git fetch doc: add a new section to explain the ins & outs of pruning
fetch tests: fetch <url> <spec> as well as fetch [<remote>]
fetch tests: expand case/esac for later change
fetch tests: double quote a variable for interpolation
fetch tests: test --prune and refspec interaction
fetch tests: add a tag to be deleted to the pruning tests
fetch tests: re-arrange arguments for future readability
fetch tests: refactor in preparation for testing tag pruning
remote: add a macro for "refs/tags/*:refs/tags/*"
fetch: stop accessing "remote" variable indirectly
fetch: trivially refactor assignment to ref_nr
fetch: don't redundantly NULL something calloc() gave us
"git tag" learned an explicit "--edit" option that allows the
message given via "-m" and "-F" to be further edited.
* nm/tag-edit:
tag: add --edit option
This adds xfuncname and word_regex patterns for golang, a quite
popular programming language. It also includes test cases for the
xfuncname regex (t4018) and updated documentation.
The xfuncname regex finds functions, structs and interfaces. Although
the Go language prohibits the opening brace from being on its own
line, the regex does not makes it mandatory, to be able to match
`func` statements like this:
func foo(bar int,
baz int) {
}
This is covered by the test case t4018/golang-long-func.
The word_regex pattern finds identifiers, integers, floats, complex
numbers and operators, according to the go specification.
Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git push" over http transport did not unquote the push-options
correctly.
* jk/push-options-via-transport-fix:
remote-curl: unquote incoming push-options
t5545: factor out http repository setup
Many places in "git apply" knew that "/dev/null" that signals
"there is no such file on this side of the diff" can be followed by
whitespace and garbage when parsing a patch, except for one, which
made an otherwise valid patch (e.g. ones from subversion) rejected.
* tk/apply-dev-null-verify-name-fix:
apply: handle Subversion diffs with /dev/null gracefully
apply: demonstrate a problem applying svn diffs
"git worktree add" learned to run the post-checkout hook, just like
"git clone" runs it upon the initial checkout.
* es/worktree-add-post-checkout-hook:
worktree: add: fix 'post-checkout' not knowing new worktree location
"git am" has learned the "--quit" option, in addition to the existing
"--abort" option; having the pair mirrors a few other commands like
"rebase" and "cherry-pick".
* nd/am-quit:
am: support --quit
GIT_DISABLE_UNTRACKED_CACHE and GIT_TEST_UNTRACKED_CACHE are only
sensed for their presense by using getenv(); use git_env_bool()
instead so that GIT_DISABLE_UNTRACKED_CACHE=false would work as
naïvely expected.
Also rename GIT_TEST_UNTRACKED_CACHE to GIT_FORCE_UNTRACKED_CACHE
to express what it does more honestly. Forcing its use may be one
useful thing to do while testing the feature, but testing does not
have to be the only use of the knob.
While at it, avoid repeated calls to git_env_bool() by capturing the
return value from the first call in a static variable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Certain information is currently shown with --summary, but when used
in combination with --stat it's a bit hard to read since info of the
same file is in two places (--stat and --summary).
On top of that, commits that add or remove files double the number of
display lines, which could be a lot if you add or remove a lot of
files.
--compact-summary embeds most of --summary back in --stat in the
little space between the file name part and the graph line, e.g. with
commit 0433d533f1:
Documentation/merge-config.txt | 4 +
builtin/merge.c | 2 +
...-pull-verify-signatures.sh (new +x) | 81 ++++++++++++++
t/t7612-merge-verify-signatures.sh | 45 ++++++++
4 files changed, 132 insertions(+)
It helps both condensing information and saving some text
space. What's new in diffstat is:
- A new 0644 file is shown as (new)
- A new 0755 file is shown as (new +x)
- A new symlink is shown as (new +l)
- A deleted file is shown as (gone)
- A mode change adding executable bit is shown as (mode +x)
- A mode change removing it is shown as (mode -x)
Note that --compact-summary does not contain all the information
--summary provides. Rewrite percentage is not shown but it could be
added later, like R50% or C20%.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
9ba95ed23c (perf/run: update get_var_from_env_or_config() for
subsections) stopped setting a default value for GIT_PERF_REPEAT_COUNT
if no perf config file is present, because get_var_from_env_or_config
returns early in that case.
Fix it by setting the default value after calling this function. Its
fifth parameter is not used for any other variable, so remove the
associated code.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The helper function test_must_be_empty is meant to make sure the
given file is empty, but its implementation is:
if test -s "$1"
then
... not empty, we detected a failure ...
fi
Surely, the file having non-zero size is a sign that the condition
"the file must be empty" is violated, but it misses the case where
the file does not even exist. It is an accident waiting to happen
with a buggy test like this:
git frotz 2>error-message &&
test_must_be_empty errro-message
that won't get caught until you deliberately break 'git frotz' and
notice why the test does not fail.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When resetting the working tree files recursively, the working tree
of submodules are now also reset to match.
* sb/submodule-update-reset-fix:
submodule: submodule_move_head omits old argument in forced case
unpack-trees: oneway_merge to update submodules
t/lib-submodule-update.sh: fix test ignoring ignored files in submodules
t/lib-submodule-update.sh: clarify test
"git commit --fixup" did not allow "-m<message>" option to be used
at the same time; allow it to annotate resulting commit with more
text.
* ab/commit-m-with-fixup:
commit: add support for --fixup <commit> -m"<extra message>"
commit doc: document that -c, -C, -F and --fixup with -m error
"git status" after moving a path in the working tree (hence making
it appear "removed") and then adding with the -N option (hence
making that appear "added") detected it as a rename, but did not
report the old and new pathnames correctly.
* nd/ita-wt-renames-in-status:
wt-status.c: handle worktree renames
wt-status.c: rename rename-related fields in wt_status_change_data
wt-status.c: catch unhandled diff status codes
wt-status.c: coding style fix
Use DIFF_DETECT_RENAME for detect_rename assignments
t2203: test status output with porcelain v2 format
Code clean-up.
* jk/test-hashmap-updates:
test-hashmap: use "unsigned int" for hash storage
test-hashmap: simplify alloc_test_entry
test-hashmap: use strbuf_getline rather than fgets
test-hashmap: use xsnprintf rather than snprintf
test-hashmap: check allocation computation for overflow
test-hashmap: use ALLOC_ARRAY rather than bare malloc
Code to unquote single-quoted string (used in the parser for
configuration files, etc.) did not diagnose bogus input correctly
and produced bogus results instead.
* jk/sq-dequote-on-bogus-input:
sq_dequote: fix extra consumption of source string
"git describe $garbage" stopped giving any errors when the garbage
happens to be a string with 40 hexadecimal letters.
* sb/describe-blob:
describe: confirm that blobs actually exist
"git check-ignore" with multiple paths got confused when one is a
file and the other is a directory, which has been fixed.
* rs/check-ignore-multi:
check-ignore: fix mix of directories and other file types
"git rebase -p" mangled log messages of a merge commit, which is
now fixed.
* js/fix-merge-arg-quoting-in-rebase-p:
rebase -p: fix incorrect commit message when calling `git merge`.
"git add" files in the same directory, but spelling the directory
path in different cases on case insensitive filesystem, corrupted
the name hash data structure and led to unexpected results. This
has been corrected.
* bp/name-hash-dirname-fix:
name-hash: properly fold directory names in adjust_dirname_case()
Some bugs around "untracked cache" feature have been fixed.
* nd/fix-untracked-cache-invalidation:
dir.c: ignore paths containing .git when invalidating untracked cache
dir.c: stop ignoring opendir() error in open_cached_dir()
dir.c: fix missing dir invalidation in untracked code
dir.c: avoid stat() in valid_cached_dir()
status: add a failing test showing a core.untrackedCache bug
Test helper functions like test_must_fail may produce
messages to stderr when they see a problem. When the tests
are run with "--verbose", this ends up on the test script's
stderr, and the user can read it.
But there's a problem. Some tests record stderr as part of
the test, like:
test_must_fail git foo 2>output &&
test_i18ngrep expected.message output
In this case the error text goes into "output". This makes
the --verbose output less useful (it also means we might
accidentally match it in the second, though in practice we
tend to produce these messages only on error, so we'd abort
the test when the first command fails).
Let's instead send this user-facing output directly to
descriptor 4, which always points to the original stderr (or
/dev/null in non-verbose mode). And it's already forbidden
to redirect descriptor 4, since we use it for BASH_XTRACEFD,
as explained in 9be795fbce (t5615: avoid re-using descriptor
4, 2017-12-08).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was an undocumented debugging aid that does not seem to
have come in handy in the past decade, judging from its lack
of mentions on the mailing list.
Let's drop it in the name of simplicity. This is morally a
revert of 3131b71301 (Add "--show-all" revision walker flag
for debugging, 2008-02-09), but note that I did leave in the
mapping of UNINTERESTING to "^" in get_revision_mark(). I
don't think this would be possible to trigger with the
current code, but it's the only sensible marker.
We'll skip the usual deprecation period because this was
explicitly a debugging aid that was never documented.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test fixes.
* sg/test-i18ngrep:
t: make 'test_i18ngrep' more informative on failure
t: validate 'test_i18ngrep's parameters
t: move 'test_i18ncmp' and 'test_i18ngrep' to 'test-lib-functions.sh'
t5536: let 'test_i18ngrep' read the file without redirection
t5510: consolidate 'grep' and 'test_i18ngrep' patterns
t4001: don't run 'git status' upstream of a pipe
t6022: don't run 'git merge' upstream of a pipe
t5812: add 'test_i18ngrep's missing filename parameter
t5541: add 'test_i18ngrep's missing filename parameter
"git format-patch" learned to give 72-cols to diffstat, which is
consistent with other line length limits the subcommand uses for
its output meant for e-mails.
* nd/format-patch-stat-width:
format-patch: reduce patch diffstat width to 72
format-patch: keep cover-letter diffstat wrapped in 72 columns
The transport-helper protocol c-style quotes the value of
any options passed to the helper via the "option <key> <value>"
directive. However, remote-curl doesn't actually unquote the
push-option values, meaning that we will send the quoted
version to the other side (whereas git-over-ssh would send
the raw value).
The pack-protocol.txt documentation defines the push-options
as a series of VCHARs, which excludes most characters that
would need quoting. But:
1. You can still see the bug with a valid push-option that
starts with a double-quote (since that triggers
quoting).
2. We do currently handle any non-NUL characters correctly
in git-over-ssh. So even though the spec does not say
that we need to handle most quoted characters, it's
nice if our behavior is consistent between protocols.
There are two new tests: the "direct" one shows that this
already works in the non-http case, and the http one covers
this bugfix.
Reported-by: Jon Simons <jon@jonsimons.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We repeat many lines of setup code in the two http tests,
and further tests would need to repeat it again. Let's
factor this out into a function.
Incidentally, this also fixes an unlikely bug: if the httpd
root path contains a double-quote, our test_when_finished
would barf due to improper quoting (we escape the embedded
quotes, but not the $, meaning we expand the variable before
the eval).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git respects XDG_CACHE_HOME for the credential cache. So, we should
unset XDG_CACHE_HOME for the test environment, lest a user's custom one
cause failure in the test.
For example, t/t0301-credential-cache.sh expects a default directory
to be used if it hasn't explicitly set XDG_CACHE_HOME.
Signed-off-by: Genki Sky <sky@genki.is>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Long time ago at fab47d05 ("merge: force edit and no-ff mode when
merging a tag object", 2011-11-07), "git merge" was made to always
create a merge commit when merging a tag, even when the side branch
being merged is a descendant of the current branch.
This default is good for merges made by upstream maintainers to
integrate work signed by downstream contributors, but will leave
pointless no-ff merges when downstream contributors pull a newer
release tag to make their long-running topic branches catch up with
the upstream. When there is no local work left on the topic, such a
merge should simply fast-forward to the commit pointed at by the
release tag.
Update the default (again) for "git merge" that merges a tag object
to (1) --no-ff (i.e. create a merge commit even when side branch
fast forwards) if the tag being merged is not at its expected place
in refs/tags/ hierarchy and (2) --ff (i.e. allow fast-forward update
when able) otherwise.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git add -p" was taught to ignore local changes to submodules as
they do not interfere with the partial addition of regular changes
anyway.
* nd/add-i-ignore-submodules:
add--interactive: ignore submodule changes except HEAD
"git stash -- <pathspec>" incorrectly blew away untracked files in
the directory that matched the pathspec, which has been corrected.
* tg/stash-with-pathspec-fix:
stash: don't delete untracked files that match pathspec
