Since 180a9f2268 (provide a facility for "delayed" progress
reporting, 2007-04-20), the progress code has allowed
callers to skip showing progress if they have reached a
percentage-threshold of the total work before the delay
period passes.
But since 8aade107dd (progress: simplify "delayed" progress
API, 2017-08-19), that parameter is not available to outside
callers (we always passed zero after that commit, though
that was corrected in the previous commit to "100%").
Let's drop the threshold code, which never triggers in
any meaningful way.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 8aade107dd (progress: simplify "delayed" progress
API, 2017-08-19) dropped the parameter by which callers
could say "show my progress only if I haven't passed M%
progress after N seconds". The intent was to just show
nothing for 2 seconds, and then always progress after that.
But we flipped the logic in the wrapper: it sets M=0,
meaning that we'd almost _never_ show progress after 2
seconds, since we'd generally have made some progress. This
should have been 100%, not 0%.
We were fooled by existing calls like:
start_progress_delay("foo", 0, 0, 2);
which behaved this way. The trick is that the first "0"
there is "how many items total", and there zero means "we
don't know". And without knowing that, we cannot compute a
completed percent at all, and we ignored the threshold
parameter entirely! Modeling our wrapper after that broke
callers which pass a non-zero value for "total".
We can switch to the intended behavior by using "100" in the
wrapper call.
Reported-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace use of strbuf_addf() with strbuf_add() when enumerating
loose objects in for_each_file_in_obj_subdir(). Since we already
check the length and hex-values of the string before consuming
the path, we can prevent extra computation by using the lower-
level method.
One consumer of for_each_file_in_obj_subdir() is the abbreviation
code. OID abbreviations use a cached list of loose objects (per
object subdirectory) to make repeated queries fast, but there is
significant cache load time when there are many loose objects.
Most repositories do not have many loose objects before repacking,
but in the GVFS case the repos can grow to have millions of loose
objects. Profiling 'git log' performance in GitForWindows on a
GVFS-enabled repo with ~2.5 million loose objects revealed 12% of
the CPU time was spent in strbuf_addf().
Add a new performance test to p4211-line-log.sh that is more
sensitive to this cache-loading. By limiting to 1000 commits, we
more closely resemble user wait time when reading history into a
pager.
For a copy of the Linux repo with two ~512 MB packfiles and ~572K
loose objects, running 'git log --oneline --parents --raw -1000'
had the following performance:
HEAD~1 HEAD
----------------------------------------
7.70(7.15+0.54) 7.44(7.09+0.29) -3.4%
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Reviewed-by: Jeff King <peff@peff.net>
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>
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>
The message spans over 2 lines but the C concatenation does not add
the needed space between the two lines.
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix a bug in the compilation of PCRE2 patterns under JIT (the most
common runtime configuration). Any pattern with a (*NO_JIT) verb would
segfault in any currently released PCRE2 version:
$ git grep -P '(*NO_JIT)hi.*there'
Segmentation fault
That this segfaulted was a bug in PCRE2 itself, after reporting it[1]
on pcre-dev it's been fixed in a yet-to-be-released version of
PCRE (presumably released first as 10.31). Now it'll die with:
$ git grep -P '(*NO_JIT)hi.*there'
fatal: pcre2_jit_match failed with error code -45: bad JIT option
But the cause of the bug is in our own code dating back to my
94da9193a6 ("grep: add support for PCRE v2", 2017-06-01).
As explained at more length in the comment being added here, it isn't
sufficient to just check pcre2_config() to see whether the JIT should
be used, pcre2_pattern_info() also has to be asked.
This is something I discovered myself when fiddling around with PCRE2
verbs in patterns passed to git. I don't expect that any user of git
has encountered this given the obscurity of passing PCRE2 verbs
through to the library, along with the relative obscurity of (*NO_JIT)
itself.
1. "How am I supposed to use PCRE2 JIT in the face of (*NO_JIT) ?"
(<CACBZZX5mMqDuWuFmi7sRBp3wH6CFyd-ghACukd=v0NN=rBMnJg@mail.gmail.com> &
https://lists.exim.org/lurker/thread/20171123.101502.7f0d38ca.en.html)
on the pcre-dev mailing list
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add LIBPCRE1 and LIBPCRE2 prerequisites which are true when git is
compiled with USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease,
respectively.
The syntax of PCRE1 and PCRE2 isn't the same in all cases (see
pcresyntax(3) and pcre2syntax(3)). If test are added that test for
those they'll need to be guarded by these new prerequisites.
The subsequent patch will make use of LIBPCRE2, so LIBPCRE1 isn't
strictly needed for now, but let's add it for consistency and so that
checking for it doesn't have to be done with the less obvious "PCRE,
!LIBPCRE2", which while semantically the same is more confusing, and
would lead to bugs if PCRE v3 is ever released as the tests would mean
v1, not any non-v2 version.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
`git stash push -m foo` uses "foo" as the message for the stash. But
`git stash push -m"foo"` does not parse successfully. Similarly
`git stash push --message="My stash message"` also fails. The stash
documentation doesn't suggest this syntax should work, but gitcli
does and my fingers have learned this pattern long ago for `commit`.
Teach `git stash` to parse -mFoo and --message=Foo the same as `git
commit` would do. Even though it's an internal function, add
similar support to create_stash() for consistency.
Signed-off-by: Phil Hord <phil.hord@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
Ideally we should only autocomplete if pull has --rebase since
they only work with it but could not figure out how to do that
and the error message of doing git pull --autostash points out
that you need --rebase so i guess it's good enough
Signed-off-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code is more understandable with 'if' instead of 'unless'.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function calls itself "required", but it does not die when it
sees an unexpected EOF.
Let's rename it to "packet_key_val_read()".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
