Merge branch 'tb/blame-force-read-cache-to-workaround-safe-crlf' into maint
When running "git blame $path" with unnormalized data in the index
for the path, the data in the working tree was blamed, even though
"git add" would not have changed what is already in the index, due
to "safe crlf" that disables the line-end conversion. It has been
corrected.
* tb/blame-force-read-cache-to-workaround-safe-crlf:
correct blame for files commited with CRLF
Merge branch 'sg/diff-multiple-identical-renames' into maint
"git diff -M" used to work better when two originally identical
files A and B got renamed to X/A and X/B by pairing A to X/A and B
to X/B, but this was broken in the 2.0 timeframe.
* sg/diff-multiple-identical-renames:
diffcore: fix iteration order of identical files during rename detection
Merge tag 'l10n-2.8.0-rnd3-fr' of git://github.com/git-l10n/git-po into maint
l10n-2.8.0-rnd3-fr
* tag 'l10n-2.8.0-rnd3-fr' of git://github.com/git-l10n/git-po:
l10n: fr: don't translate "merge" as a parameter
l10n: fr: change "id de clé" to match "id-clé"
l10n: fr: fix wrongly translated option name
l10n: fr: fix transcation of "dir"
Merge branch 'fr_v2.8.0_r3' of git://github.com/jnavila/git into maint
* 'fr_v2.8.0_r3' of git://github.com/jnavila/git:
l10n: fr: don't translate "merge" as a parameter
l10n: fr: change "id de clé" to match "id-clé"
l10n: fr: fix wrongly translated option name
l10n: fr: fix transcation of "dir"
Merge branch 'jv/merge-nothing-into-void' into maint
"git merge FETCH_HEAD" dereferenced NULL pointer when merging
nothing into an unborn history (which is arguably unusual usage,
which perhaps was the reason why nobody noticed it).
* jv/merge-nothing-into-void:
merge: fix NULL pointer dereference when merging nothing into void
When "git merge --squash" stopped due to conflict, the concluding
"git commit" failed to read in the SQUASH_MSG that shows the log
messages from all the squashed commits.
* ss/commit-squash-msg:
commit: do not lose SQUASH_MSG contents
The startup_info data, which records if we are working inside a
repository (among other things), are now uniformly available to Git
subcommand implementations, and Git avoids attempting to touch
references when we are not in a repository.
* jk/startup-info:
use setup_git_directory() in test-* programs
grep: turn off gitlink detection for --no-index
mailmap: do not resolve blobs in a non-repository
remote: don't resolve HEAD in non-repository
setup: set startup_info->have_repository more reliably
setup: make startup_info available everywhere
Merge branch 'jk/rev-parse-local-env-vars' into maint
The "--local-env-vars" and "--resolve-git-dir" options of "git
rev-parse" failed to work outside a repository when the command's
option parsing was rewritten in 1.8.5 era.
* jk/rev-parse-local-env-vars:
rev-parse: let some options run outside repository
t1515: add tests for rev-parse out-of-repo helpers
"git config --get-urlmatch", unlike other variants of the "git
config --get" family, did not signal error with its exit status
when there was no matching configuration.
* jk/config-get-urlmatch:
Documentation/git-config: fix --get-all description
Documentation/git-config: use bulleted list for exit codes
config: fail if --get-urlmatch finds no value
git blame reports lines as not "Not Committed Yet" when they have
CRLF in the index, CRLF in the worktree and core.autocrlf is true.
Since commit c4805393 (autocrlf: Make it work also for un-normalized
repositories, 2010-05-12), files that have CRLF in the index are not
normalized at commit when core.autocrl is set.
Add a call to read_cache() early in fake_working_tree_commit(),
before calling convert_to_git().
Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In general "echo 2>&1 $msg" to redirect a possible error message
that comes from 'echo' itself into the same standard output stream
$msg is getting written to does not make any sense; it is not like
we are expecting to see any errors out of 'echo' in these statements,
and even if it were the case, there is no reason to prevent the
error messages from being sent to the standard error stream.
These are clearly meant to send the argument given to echo to the
standard error stream as error messages. Correctly redirect by
saying "send what is written to the standard output to the standard
error", i.e. "1>&2" aka ">&2".
Windows: shorten code by re-using convert_slashes()
Make a few more spots more readable by using the recently introduced,
Windows-specific helper.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The file was renamed in 4ad21f5 (README: use markdown syntax,
2016-02-25), but that commit forgot to update git.spec.in, which
caused the rpmbuild target in the Makefile to fail.
Reported-by: Ron Isaacson <isaacson.ljits@gmail.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-send-pack: fix --all option when used with directory
When using git send-pack with --all option
and a target repository specification ([<host>:]<directory>),
usage message is being displayed instead of performing
the actual transmission.
The reason for this issue is that destination and refspecs are being set
in the same conditional and are populated from argv. When a target
repository is passed, refspecs is being populated as well with its value.
This makes the check for refspecs not being NULL to always return true,
which, in conjunction with the check for --all or --mirror options,
is always true as well and returns usage message instead of proceeding.
This ensures that send-pack will stop execution only when --all
or --mirror switch is used in conjunction with any refspecs passed.
Signed-off-by: Stanislav Kolotinskiy <stanislav@assembla.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore: fix iteration order of identical files during rename detection
If the two paths 'dir/A/file' and 'dir/B/file' have identical content
and the parent directory is renamed, e.g. 'git mv dir other-dir', then
diffcore reports the following exact renames:
While technically not wrong, this is confusing not only for the user,
but also for git commands that make decisions based on rename
information, e.g. 'git log --follow other-dir/A/file' follows
'dir/B/file' past the rename.
This behavior is a side effect of commit v2.0.0-rc4~8^2~14
(diffcore-rename.c: simplify finding exact renames, 2013-11-14): the
hashmap storing sources returns entries from the same bucket, i.e.
sources matching the current destination, in LIFO order. Thus the
iteration first examines 'other-dir/A/file' and 'dir/B/file' and, upon
finding identical content and basename, reports an exact rename.
Other hashmap users are apparently happy with the current iteration
order over the entries of a bucket. Changing the iteration order
would risk upsetting other hashmap users and would increase the memory
footprint of each bucket by a pointer to the tail element.
Fill the hashmap with source entries in reverse order to restore the
original exact rename detection behavior.
Reported-by: Bill Okara <billokara@gmail.com> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Sven Strickroth <sven@cs-ware.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Acked-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more
In MSVC2015 the behavior of vsnprintf was changed.
W/o this fix there is one character missing at the end.
Signed-off-by: Sven Strickroth <sven@cs-ware.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Acked-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
OPT_CMDMODE mechanism was introduced in the release of 1.8.5 to actively
notice when multiple "operation mode" options that specify mutually
incompatible operation modes are given.
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
At builtin/tag.c:23 French message translation, "<key-id>" was
translated to "<id-clé>", but at builtin/tag.c:355 "key-id" was
translated to "id de clé", hence an inconsistency in git tag -h output.
Translate "key-id" to "id-clé".
Alternatively, both places could use "id de clé" instead of "id-clé".
* js/mingw-tests-2.8:
mingw: skip some tests in t9115 due to file name issues
t1300: fix the new --show-origin tests on Windows
t1300-repo-config: make it resilient to being run via 'sh -x'
config --show-origin: report paths with forward slashes
The hashmap API provides hashmap_iter_first() helper for initialion
and getting the first entry of a hashmap. Let's use it instead of
doing initialization manually and then get the first entry.
There are no functional changes, just cleanup.
Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge: fix NULL pointer dereference when merging nothing into void
When we are on an unborn branch and merging only one foreign parent,
we allow "git merge" to fast-forward to that foreign parent commit.
This codepath incorrectly attempted to dereference the list of
parents that the merge is going to record even when the list is
empty. It must refuse to operate instead when there is no parent.
All other codepaths make sure the list is not empty before they
dereference it, and are safe.
Reported-by: Jose Ivan B. Vilarouca Filho Signed-off-by: Junio C Hamano <gitster@pobox.com>
Noticed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
mingw: skip some tests in t9115 due to file name issues
These two tests wanted to write file names which are incompatible with
Windows' file naming rules (even if they pass using Cygwin due to
Cygwin's magic path mangling).
While at it, skip the same tests also on MacOSX/HFS, as pointed out by
Torsten Bögershausen.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, we have that funny situation where the test script can refer
to POSIX paths because it runs in a shell that uses a POSIX emulation
layer ("MSYS2 runtime"). Yet, git.exe does *not* understand POSIX paths
at all but only pure Windows paths.
So let's just convert the POSIX paths to Windows paths before passing
them on to Git, using `pwd` (which is already modified on Windows to
output Windows paths).
While fixing the new tests on Windows, we also have to exclude the tests
that want to write a file with a name that is illegal on Windows
(unfortunately, there is more than one test trying to make use of that
file).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t1300-repo-config: make it resilient to being run via 'sh -x'
One way to diagnose broken regression tests is to run the test
script using 'sh -x t... -i -v' to find out which call actually
demonstrates the symptom.
Hence it is pretty counterproductive if the test script behaves
differently when being run via 'sh -x', in particular when using
test_cmp or test_i18ncmp on redirected stderr. A more recent way
"sh tXXXX -i -v -x" has the same issue.
So let's use test_i18ngrep (as suggested by Jonathan Nieder) instead of
test_cmp/test_i18ncmp to verify that stderr looks as expected.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule: fix regression for deinit without submodules
Per Cederqvist wrote:
> It used to be possible to run
>
> git submodule deinit -f .
>
> to remove any submodules, no matter how many submodules you had. That
> is no longer possible in projects that don't have any submodules at
> all. The command will fail with:
>
> error: pathspec '.' did not match any file(s) known to git.
This regression was introduced in 74703a1e4dfc (submodule: rewrite
`module_list` shell function in C, 2015-09-02), as we changed the
order of checking in new module listing to first check whether it is
a gitlin before feeding it to match_pathspec(). It used to be that
a pathspec that does not match any path were diagnosed as an error,
but the new code complains for a pathspec that does not match any
submodule path.
Arguably the new behaviour may give us a better diagnosis, but that
is inconsistent with the suggestion "deinit" gives, and also this
was an unintended accident. The new behaviour hopefully can be
redesigned and implemented better in future releases, but for now,
switch these two checks to restore the same behavior as before. In
an empty repository, giving the pathspec '.' will still get the same
"did not match" error, but that is the same bug we had before 1.7.0.
Reported-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When concluding a conflicted "git merge --squash", the command
failed to read SQUASH_MSG that was prepared by "git merge", and
showed only the "# Conflicts:" list of conflicted paths.
Place the contents from SQUASH_MSG at the beginning, just like we
show the commit log skeleton first when concluding a normal merge,
and then show the "# Conflicts:" list, to help the user write the
log message for the resulting commit.
Test by Junio C Hamano <gitster@pobox.com>.
Signed-off-by: Sven Strickroth <sven@cs-ware.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that st_add4() has been patched to work around the gcc 4.2.x
compiler crash, revert the sledge-hammer approach of forcing Mac OS X
10.6 to unconditionally use 'clang' rather than the default compiler
(gcc).
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-compat-util: st_add4: work around gcc 4.2.x compiler crash
Although changes by 5b442c4 (tree-diff: catch integer overflow in
combine_diff_path allocation, 2016-02-19) are perfectly valid, they
unfortunately trigger an internal compiler error in gcc 4.2.x:
combine-diff.c: In function 'diff_tree_combined':
combine-diff.c:1391: internal compiler error: Segmentation fault: 11
Experimentation reveals that changing st_add4()'s argument evaluation
order is sufficient to sidestep this problem.
Although st_add3() does not trigger the compiler bug, for style
consistency, change its argument evaluation order to match.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'master' of git://ozlabs.org/~paulus/gitk
* 'master' of git://ozlabs.org/~paulus/gitk:
gitk: Follow themed bgcolor in help dialogs
gitk: fr.po: Sync translations with git
gitk: Update French translation (311t)
gitk: Update German translation
gitk: Update Bulgarian translation (311t)
We set GIT_CONFIG_NOSYSTEM in our test scripts so that we do
not accidentally read /etc/gitconfig and have it influence
the outcome of the tests. But when running smart-http tests,
Apache will clean the environment, including this variable,
and the "server" side of our http operations will read it.
You can see this breakage by doing something like:
make
./git config --system http.getanyfile false
make test
which will cause t5561 to fail when it tests the
fallback-to-dumb operation.
We can fix this by instructing Apache to pass through the
variable. Unlike with other variables (e.g., 89c57ab3's
GIT_TRACE), we don't need to set a dummy value to prevent
warnings from Apache. test-lib.sh already makes sure that
GIT_CONFIG_NOSYSTEM is set and exported.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When this code was originally written, there wasn't much
thought given to the timing between a client asking for
"exit", the daemon signaling that the action is done (with
EOF), and the actual cleanup of the socket.
However, we need to care about this so that our test scripts
do not end up racy (e.g., by asking for an exit and checking
that the socket was cleaned up). The code that is already
there happens to behave very reasonably; let's add a comment
to make it clear that any changes should retain the same
behavior.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email: ignore trailing whitespace in mailrc alias file
The regex for parsing mailrc considers everything after the
second whitespace to be the email address, up to the end of
the line. We have to include whitespace there, because you
may have multiple space-separated addresses, each with their
own internal quoting.
But if there is trailing whitespace, we include that, too.
This confuses quotewords() when we try to split the
individual addresses, and we end up storing "undef" in our
alias list. Later parts of the code then access that,
generating perl warnings.
Let's tweak our regex to throw away any trailing whitespace
on each line.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>