"git config" failed to update the configuration file when the
underlying filesystem is incapable of renaming a file that is still
open.
* kb/config-unmap-before-renaming:
config.c: fix writing config files on Windows network shares
When you say "!<ENTER>" while running say "git log", you'd confuse
yourself in the resulting shell, that may look as if you took
control back to the original shell you spawned "git log" from but
that isn't what is happening. To that new shell, we leaked
GIT_PAGER_IN_USE environment variable that was meant as a local
communication between the original "Git" and subprocesses that was
spawned by it after we launched the pager, which caused many
"interesting" things to happen, e.g. "git diff | cat" still paints
its output in color by default.
Stop leaking that environment variable to the pager's half of the
fork; we only need it on "Git" side when we spawn the pager.
* jc/unexport-git-pager-in-use-in-pager:
pager: do not leak "GIT_PAGER_IN_USE" to the pager
Abandoning an already applied change in "git rebase -i" with
"--continue" left CHERRY_PICK_HEAD and confused later steps.
* js/rebase-i-clean-up-upon-continue-to-skip:
rebase -i: do not leave a CHERRY_PICK_HEAD file behind
t3404: demonstrate CHERRY_PICK_HEAD bug
We used to ask libCURL to use the most secure authentication method
available when talking to an HTTP proxy only when we were told to
talk to one via configuration variables. We now ask libCURL to
always use the most secure authentication method, because the user
can tell libCURL to use an HTTP proxy via an environment variable
without using configuration variables.
* et/http-proxyauth:
http: always use any proxy auth method available
A fix to a minor regression to "git fsck" in v2.2 era that started
complaining about a body-less tag object when it lacks a separator
empty line after its header to separate it with a non-existent body.
* jc/fsck-retire-require-eoh:
fsck: it is OK for a tag and a commit to lack the body
"git rebase" did not exit with failure when format-patch it invoked
failed for whatever reason.
* cb/rebase-am-exit-code:
rebase: return non-zero error code if format-patch fails
A minor bugfix when pack bitmap is used with "rev-list --count".
* jk/rev-list-no-bitmap-while-pruning:
rev-list: disable --use-bitmap-index when pruning commits
Tests update in contrib/subtree.
* cb/subtree-tests-update:
contrib/subtree: small tidy-up to test
contrib/subtree: fix broken &&-chains and revealed test error
contrib/subtree: use tabs consitently for indentation in tests
An ancient test framework enhancement to allow color was not
entirely correct; this makes it work even when tput needs to read
from the ~/.terminfo under the user's real HOME directory.
* rh/test-color-avoid-terminfo-in-original-home:
test-lib.sh: fix color support when tput needs ~/.terminfo
Revert "test-lib.sh: do tests for color support after changing HOME"
The for_each_packed_object() API function did not iterate over
objects in a packfile that hasn't been used yet.
* jk/maint-for-each-packed-object:
for_each_packed_object: automatically open pack index
When we want to write out a loose object file, we have
always first made sure we don't already have the object
somewhere. Since 33d4221 (write_sha1_file: freshen existing
objects, 2014-10-15), we also update the timestamp on the
file, so that a simultaneous prune knows somebody is
likely to reference it soon.
If our utime() call fails, we treat this the same as not
having the object in the first place; the safe thing to do
is write out another copy. However, the loose-object check
accidentally inverts the utime() check; it returns failure
_only_ when the utime() call actually succeeded. Thus it was
failing to protect us there, and in the normal case where
utime() succeeds, it caused us to pointlessly write out and
link the object.
This passed our freshening tests, because writing out the
new object is certainly _one_ way of updating its utime. So
the normal case was inefficient, but not wrong.
While we're here, let's also drop a comment in front of the
check_and_freshen functions, making a note of their return
type (since it is not our usual "0 for success, -1 for
error").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since e481af06 (rebase: Handle cases where format-patch fails) we
notice if format-patch fails and return immediately from
git-rebase--am. We save the return value with ret=$?, but then we
return $?, which is usually zero in this case.
Fix this by returning $ret instead.
Cc: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Clemens Buchacher <clemens.buchacher@intel.com>
Helped-by: Jorge Nunes <jorge.nunes@intel.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that we have proper documentation for --force's interaction with -d
and -m, we can avoid duplication and consider -M and -D as convenience
aliases for -m --force and -d --force.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --force option was modified in 356e91f (branch: allow -f with -m and
-d, 2014-12-08), but the documentation was not updated.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The only change is a bugfix: the SMTP mailer was not working with
Python 2.4.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When c6458e60 (index-pack: kill union delta_base to save memory,
2015-04-18) attempted to reduce the memory footprint of index-pack,
one of the key thing it did was to keep track of ref-deltas and
ofs-deltas separately.
In fix_unresolved_deltas(), however it forgot that it now wants to
look only at ref deltas in one place. The code allocated an array
for nr_unresolved, which is sum of number of ref- and ofs-deltas
minus nr_resolved, which may be larger or smaller than the number
ref-deltas. Depending on nr_resolved, this was either under or over
allocating.
Also, the old code before this change had to use 'i' and 'n' because
some of the things we see in the (old) deltas[] array we scanned
with 'i' would not make it into the sorted_by_pos[] array in the old
world order, but now because you have only ref delta in a separate
ref_deltas[] array, they increment lock&step. We no longer need
separate variables. And most importantly, we shouldn't pass the
nr_unresolved parameter, as this number does not play a role in the
working of this helper function.
Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is currently declared to return int, which could overflow for
large files.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 2e6c012e (setup_pager: set GIT_PAGER_IN_USE, 2011-08-17), we
export GIT_PAGER_IN_USE so that a process that becomes the upstream
of the spawned pager can still tell that we have spawned the pager
and decide to do colored output even when its output no longer goes
to a terminal (i.e. isatty(1)).
But we forgot to clear it from the enviornment of the spawned pager.
This is not a problem in a sane world, but if you have a handful of
thousands Git users in your organization, somebody is bound to do
strange things, e.g. typing "!<ENTER>" instead of 'q' to get control
back from $LESS. GIT_PAGER_IN_USE is still set in that subshell
spawned by "less", and all sorts of interesting things starts
happening, e.g. "git diff | cat" starts coloring its output.
We can clear the environment variable in the half of the fork that
runs the pager to avoid the confusion.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git fetch --depth=<depth>" and "git clone --depth=<depth>" issued
a shallow transfer request even to an upload-pack that does not
support the capability.
* me/fetch-into-shallow-safety:
fetch-pack: check for shallow if depth given
Hotfix for an earlier change already in 'master' that broke the
default tool selection for mergetool.
* da/mergetool-winmerge:
mergetool-lib: fix default tool selection
The reachability bitmaps do not have enough information to
tell us which commits might have changed path "foo", so the
current code produces wrong answers for:
git rev-list --use-bitmap-index --count HEAD -- foo
(it silently ignores the "foo" limiter). Instead, we should
fall back to doing a normal traversal (it is OK to fall
back rather than complain, because --use-bitmap-index is a
pure optimization, and might not kick in for other reasons,
such as there being no bitmaps in the repository).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 28fcc0b (pathspec: avoid the need of "--" when wildcard is used -
2015-05-02) changes how the disambiguation rules work. This patch adds
some tests to demonstrate, basically, if wildcard characters are in an
argument:
- if the argument is valid extended sha-1 syntax, "--" must be used
- otherwise the argument is considered a path, even without "--"
And wildcard can appear in extended sha-1 syntax, either as part of
regex in ":/<regex>" or as the literal path in ":<path>". The latter
case is less likely to happen in real world. But if you do ":/" a lot,
you may need to type "--" more.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--count should be mentioned in the usage guide, this updates code and
documentation.
Signed-off-by: Lawrence Siebert <lawrencesiebert@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Renaming to an existing file doesn't work on Windows network shares if the
target file is open.
munmap() the old config file before commit_lock_file.
Signed-off-by: Karsten Blees <blees@dcon.de>
Acked-by: Jeff King <peff@peff.net>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When skipping commits whose changes were already applied via `git rebase
--continue`, we need to clean up said file explicitly.
The same is not true for `git rebase --skip` because that will execute
`git reset --hard` as part of the "skip" handling in git-rebase.sh, even
before git-rebase--interactive.sh is called.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When rev-list's --cherry option does not detect that a patch has already
been applied upstream, an interactive rebase would offer to reapply it and
consequently stop at that patch with a failure, mentioning that the diff
is empty.
Traditionally, a `git rebase --continue` simply skips the commit in such a
situation.
However, as pointed out by Gábor Szeder, this leaves a CHERRY_PICK_HEAD
behind, making the Git prompt believe that a cherry pick is still going
on. This commit adds a test case demonstrating this bug.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We set CURLOPT_PROXYAUTH to use the most secure authentication
method available only when the user has set configuration variables
to specify a proxy. However, libcurl also supports specifying a
proxy through environment variables. In that case libcurl defaults
to only using the Basic proxy authentication method, because we do
not use CURLOPT_PROXYAUTH.
Set CURLOPT_PROXYAUTH to always use the most secure authentication
method available, even when there is no git configuration telling us
to use a proxy. This allows the user to use environment variables to
configure a proxy that requires an authentication method different
from Basic.
Signed-off-by: Enrique A. Tobis <etobis@twosigma.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When fsck validates a commit or a tag, it scans each line in the
header of the object using helper functions such as "start_with()",
etc. that work on a NUL terminated buffer, but before a1e920a0
(index-pack: terminate object buffers with NUL, 2014-12-08), the
validation functions were fed the object data in a piece of memory
that is not necessarily terminated with a NUL.
We added a helper function require_end_of_header() to be called at
the beginning of these validation functions to insist that the
object data contains an empty line before its end. The theory is
that the validating functions will notice and stop when it hits an
empty line as a normal end of header (or a required header line that
is missing) without scanning past the end of potentially not
NUL-terminated buffer.
But the theory forgot that in the older days, Git itself happily
created objects with only the header lines without a body. This
caused Git 2.2 and later to issue an unnecessary warning in some
existing repositories.
With a1e920a0, we do not need to require an empty line (or the body)
in these objects to safely parse and validate them. Drop the
offending "must have an empty line" check from this helper function,
while keeping the other check to make sure that there is no NUL in
the header part of the object, and adjust the name of the helper to
what it does accordingly.
Noticed-by: Wolfgang Denk <wd@denx.de>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
