An earlier addition of "sanitize_submodule_env" with 14111fc4 (git:
submodule honor -c credential.* from command line, 2016-02-29)
turned out to be a convoluted no-op; implement what it wanted to do
correctly, and stop filtering settings given via "git -c var=val".
* jk/submodule-c-credential:
submodule: stop sanitizing config options
submodule: use prepare_submodule_repo_env consistently
submodule--helper: move config-sanitizing to submodule.c
submodule: export sanitized GIT_CONFIG_PARAMETERS
t5550: break submodule config test into multiple sub-tests
t5550: fix typo in $HTTPD_URL
* va/i18n-misc-updates:
i18n: unpack-trees: avoid substituting only a verb in sentences
i18n: builtin/pull.c: split strings marked for translation
i18n: builtin/pull.c: mark placeholders for translation
i18n: git-parse-remote.sh: mark strings for translation
i18n: branch: move comment for translators
i18n: branch: unmark string for translation
i18n: builtin/rm.c: remove a comma ',' from string
i18n: unpack-trees: mark strings for translation
i18n: builtin/branch.c: mark option for translation
i18n: index-pack: use plural string instead of normal one
Correct faulty recommendation to use "git submodule deinit ." when
de-initialising all submodules, which would result in a strange
error message in a pathological corner case.
* sb/submodule-deinit-all:
submodule deinit: require '--all' instead of '.' for all submodules
A new configuration variable core.hooksPath allows customizing
where the hook directory is.
* ab/hooks:
hooks: allow customizing where the hook directory is
githooks.txt: minor improvements to the grammar & phrasing
githooks.txt: amend dangerous advice about 'update' hook ACL
githooks.txt: improve the intro section
Update of "git submodule" to move pieces of logic to C continues.
* sb/submodule-init:
submodule init: redirect stdout to stderr
submodule--helper update-clone: abort gracefully on missing .gitmodules
submodule init: fail gracefully with a missing .gitmodules file
submodule: port init from shell to C
submodule: port resolve_relative_url from shell to C
The final batch of git-rev-parse tests work against a non-local object
database named repo.git. This is done by renaming .git to repo.git and
pointing GIT_DIR at it, but the name is never restored to .git at the
end of the script, which can be problematic for tests added in the
future. Be more friendly by instead making repo.git a copy of .git.
Furthermore, make it clear that tests in repo.git will be independent
from the results of earlier tests done in .git by initializing repo.git
earlier in the test sequence.
Likewise, bundle remaining preparation (such as directory creation) into
a common setup test consistent with modern practice.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When files are unmerged they can show up as both unmerged and
modified in the output of `git diff --raw`. This causes
difftool's dir-diff to create filesystem entries for the same
path twice, which fails when it encounters a duplicate path.
Ensure that each worktree path is only processed once.
Add a test to demonstrate the breakage.
Reported-by: Jan Smets <jan@smets.cx> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
that does not quote its arguments, it's easy to think that
it is actually looking at the contents of $foo in each case.
But if $foo is empty, then "test" does not see any argument
at all! The results are quite subtle.
POSIX specifies that test's behavior depends on the number
of arguments it sees, and if $foo is empty, it sees only
one. The behavior in this case is:
1 argument: Exit true (0) if $1 is not null; otherwise,
exit false.
So in the "-z $foo" case, if $foo is empty, then we check
that "-z" is non-null, and it returns success. Which happens
to match what we expected. But for "-n $foo", if $foo is
empty, we'll see that "-n" is non-null and still return
success. That's the opposite of what we intended!
Furthermore, if $foo contains whitespace, we'll end up with
more than 2 arguments. The results in this case are
generally unspecified (unless the first part of $foo happens
to be a valid binary operator, in which case the results are
specified but certainly not what we intended).
And on top of this, even though "test -z $foo" _should_ work
for the empty case, some older shells (reportedly ksh88)
complain about the missing argument.
So let's make sure we consistently quote our variable
arguments to "test". After this patch, the results of:
git grep 'test -[zn] [^"]'
are empty.
Reported-by: Armin Kunaschik <megabreit@googlemail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The main goal here was to avoid double-quotes for
surrounding the test snippet, since it makes the code hard
to read (and to grep for common problems).
But while we're here, we can fix a few other things:
- use test_path_* helpers, which are more robust and give
better error messages
- only "cd" inside a subshell, which leaves the
environment pristine if further tests are added
- consistently quote shell arguments. These aren't wrong
if we assume find-rev output doesn't have any
whitespace, but it doesn't hurt to be careful.
- replace the old-style 'test x$foo = x' with 'test -z
"$foo"'. Besides the quoting fix, this is the form we
generally use in our test suite.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t9107: switch inverted single/double quotes in test
One of the test snippets in t9107 is enclosed in double
quotes, but then uses single quotes to surround an
interpolated variable inside the snippet, like:
test_expect_success '...' "
test -n '$head'
"
This happens to work because the variable is interpolated
_before_ the snippet is run, and the result is eval'd. So as
long as the variable does not contain any single quotes, the
two are equivalent. And it doesn't, as we know it is a sha1
from rev-parse above. But this construct is unnecessarily
confusing.
But we can go a step further in cleaning up. The test is
really checking that a particular ref has a value. Rather
than checking if rev-parse produced output, we can just move
rev-parse into the test itself, and rely on the exit code
from --verify. Nobody else cares about the $head variable at
all.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a test runs a loop, it cannot rely on the usual
&&-chaining to propagate a failure inside the loop; it needs
to break out with a failure signal. However, unless you are
in a subshell, doing so with "exit 1" will exit the entire
test script, not just the test snippet we are in (and cause
the harness to complain that test_done was never reached).
So the fundamental point of this patch is s/exit/return/.
But while we're there, let's fix a number of style and
readability issues:
- snippets in double-quotes need an extra layer of quoting
for their meta-characters; let's avoid that by using
single quotes
- accumulating loop output by appending to a file in each
iteration is brittle, as it can be affected by content
left in the file by earlier tests. Instead, it's better
to redirect stdout for the whole loop, so we know the
output only comes from that loop.
- using "test -z" to check that diff output is empty is
overly verbose; we can just ask diff to use --exit-code.
- we can factor out long lists of refs to make it more
obvious we're using the same ones in each loop
- subshells are unnecessary when ending an &&-chain with
"|| return 1"
- minor style fixups like space-after-redirection, and
"do" and "done" on their own lines
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running diff commands, a pathspec containing decomposed
unicode code points is not converted to precomposed unicode form
under Mac OS X, but we normalize the paths in the index and the
history to precomposed form on that platform. As a result, the
pathspec would not match and no diff is shown.
Unlike many builtin commands, the "diff" family of commands do
not use parse_options(), which is how other builtin commands
indirectly call precompose_argv() to normalize argv[] into
precomposed form on Mac OSX. Teach these commands to call
precompose_argv() themselves.
Note that precomopose_argv() normalizes not just paths but all
command line arguments, so things like "git diff -G $string"
when $string has the decomposed form would first be normalized
into the precomposed form and would stop hitting the same string
in the decomposed form in the diff output with this change.
It is not a problem per-se, as "log" family of commands already use
parse_options() and call precompose_argv()--we can think of this
change as making the "diff" family of commands behave in a similar
way as the commands in the "log" family.
Signed-off-by: Alexander Rinass <alex@fournova.com> Helped-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t9100,t3419: enclose all test code in single-quotes
A few tests here use double-quotes around the snippets of
shell code to run the tests. None of these tests wants to do
any interpolation at all, and it just leads to an extra
layer of quoting around all double-quotes and dollar signs
inside the snippet. Let's switch to single quotes, like
most other test scripts.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git commit-tree" plumbing command required the user to always sign
its result when the user sets the commit.gpgsign configuration
variable, which was an ancient mistake. Rework "git rebase" that
relied on this mistake so that it reads commit.gpgsign and pass (or
not pass) the -S option to "git commit-tree" to keep the end-user
expectation the same, while teaching "git commit-tree" to ignore
the configuration variable. This will stop requiring the users to
sign commit objects used internally as an implementation detail of
"git stash".
* jc/commit-tree-ignore-commit-gpgsign:
commit-tree: do not pay attention to commit.gpgsign
Clarify that "merge --verify-signatures" checks the signature on the
tip commit of the history being merged.
Uniformise the vocabulary used wrt. key/signature validity with OpenPGP:
- a signature is valid if made by a key with a valid uid;
- in the default trust-model, a uid is valid if signed by a trusted key;
- a key is trusted if the (local) user set a trust level for it.
Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Keller Fuchs <KellerFuchs@hashbang.sh> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This developer spent a lot of time trying to speed up the interactive
rebase, in particular on Windows. And will continue to do so.
To make it easier to demonstrate the performance improvement, let's have
a reproducible performance test.
The topic branch we use to test performance was found using these shell
commands (essentially searching for a long-enough topic branch in Git's
own history that touched the same file multiple times):
git rev-list --parents origin/master |
grep ' .* ' |
while read commit rest
do
patch_count=$(git rev-list --count $commit^..$commit^2)
test $patch_count -gt 20 || continue
Note that we can get away with *not* having to reset to the original
branch tip before rebasing: we switch the first two "pick" lines every
time, so we end up with the same patch order after two rebases, and the
complexity of both rebases is equivalent.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch makes perf-lib.sh more robust so that it can run correctly
even inside a worktree. For example, it assumed that $GIT_DIR/objects is
the objects directory (which is not the case for worktrees) and it used
the commondir file verbatim, even if it contained a relative path.
Furthermore, the setup code expected `git rev-parse --git-dir` to spit
out a relative path, which is also not true for worktrees. Let's just
change the code to accept both relative and absolute paths, by avoiding
the `cd` into the copied working directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
perf: let's disable symlinks when they are not available
We already have a perfectly fine prereq to tell us whether it is safe to
use symlinks. So let's use it.
This fixes the performance tests in Git for Windows' SDK, where symlinks
are not really available ([*1*]). This is not an issue with Git for
Windows itself because it configures core.symlinks=false in its system
config. However, the system config is disabled for the performance
tests, for obvious reasons: we want them to be independent of the
vagaries of any local configuration.
Footnote *1*: Windows has symbolic links. Git for Windows disables them
by default, though (for example: in standard setups, non-admins lack the
privilege to create symbolic links). For details, see
https://github.com/git-for-windows/git/wiki/Symbolic-Links
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
i18n: unpack-trees: avoid substituting only a verb in sentences
Instead of reusing the same set of message templates for checkout
and other actions and substituting the verb with "%s", prepare
separate message templates for each known action. That would make
it easier for translation into languages where the same verb may
conjugate differently depending on the message we are giving.
See gettext documentation for details:
http://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html
Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Passing "-x" to a test script enables the shell's "set -x"
tracing, which can help with tracking down the command that
is causing a failure. Unfortunately, it can also _cause_
failures in some tests that redirect the stderr of a shell
function. Inside the function the shell continues to
respect "set -x", and the trace output is collected along
with whatever stderr is generated normally by the function.
You can see an example of this by running:
./t0040-parse-options.sh -x -i
which will fail immediately in the first test, as it
expects:
test_must_fail some-cmd 2>output.err
to leave output.err empty (but with "-x" it has our trace
output).
Unfortunately there isn't a portable or scalable solution to
this. We could teach test_must_fail to disable "set -x", but
that doesn't help any of the other functions or subshells.
However, we can work around it by pointing the "set -x"
output to our descriptor 4, which always points to the
original stderr of the test script. Unfortunately this only
works for bash, but it's better than nothing (and other
shells will just ignore the BASH_XTRACEFD variable).
The patch itself is a simple one-liner, but note the caveats
in the accompanying comments.
Automatic tests for our "-x" option may be a bit too meta
(and a pain, because they are bash-specific), but I did
confirm that it works correctly both with regular "-x" and
with "--verbose-only=1". This works because the latter flips
"set -x" off and on for particular tests (if it didn't, we
would get tracing for all tests, as going to descriptor 4
effectively circumvents the verbose flag).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Windows: only add a no-op pthread_sigmask() when needed
In f924b52 (Windows: add pthread_sigmask() that does nothing,
2016-05-01), we introduced a no-op for Windows. However, this breaks
building Git in Git for Windows' SDK because pthread_sigmask() is
already a no-op there, #define'd in the pthread_signal.h header in
/mingw64/x86_64-w64-mingw32/include/.
Let's wrap the definition of pthread_sigmask() in a guard that skips
it when compiling with MinGW-w64' headers.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
For some reason, the definition of the MINGW version of
`mark_as_git_dir()` slipped into this developer's patch series to
support building Git for Windows.
As the `mark_as_git_dir()` function is not needed at all anymore (it was
used originally to support the core.hideDotFiles = gitDirOnly setting,
but we now use a different method to support that case), let's just
remove it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Unix (and Linux), files and directories whose names start with a dot
are usually not shown by default. This convention is used by Git: the
.git/ directory should be left alone by regular users, and only accessed
through Git itself.
On Windows, no such convention exists. Instead, there is an explicit flag
to mark files or directories as hidden.
In the early days, Git for Windows did not mark the .git/ directory (or
for that matter, any file or directory whose name starts with a dot)
hidden. This lead to quite a bit of confusion, and even loss of data.
Consequently, Git for Windows introduced the core.hideDotFiles setting,
with three possible values: true, false, and dotGitOnly, defaulting to
marking only the .git/ directory as hidden.
The rationale: users do not need to access .git/ directly, and indeed (as
was demonstrated) should not really see that directory, either. However,
not all dot files should be hidden by default, as e.g. Eclipse does not
show them (and the user would therefore be unable to see, say, a
.gitattributes file).
In over five years since the last attempt to bring this patch into core
Git, a slightly buggy version of this patch has served Git for Windows'
users well: no single report indicated problems with the hidden .git/
directory, and the stream of problems caused by the previously non-hidden
.git/ directory simply stopped. The bugs have been fixed during the
process of getting this patch upstream.
Note that there is a funny quirk we have to pay attention to when
creating hidden files: we use Win32's _wopen() function which
transmogrifies its arguments and hands off to Win32's CreateFile()
function. That latter function errors out with ERROR_ACCESS_DENIED (the
equivalent of EACCES) when the equivalent of the O_CREAT flag was passed
and the file attributes (including the hidden flag) do not match an
existing file's. And _wopen() accepts no parameter that would be
transmogrified into said hidden flag. Therefore, we simply try again
without O_CREAT.
A slightly different method is required for our fopen()/freopen()
function as we cannot even *remove* the implicit O_CREAT flag.
Therefore, we briefly mark existing files as unhidden when opening them
via fopen()/freopen().
The ERROR_ACCESS_DENIED error can also be triggered by opening a file
that is marked as a system file (which is unlikely to be tracked in
Git), and by trying to create a file that has *just* been deleted and is
awaiting the last open handles to be released (which would be handled
better by the "Try again?" logic, a story for a different patch series,
though). In both cases, it does not matter much if we try again without
the O_CREAT flag, read: it does not hurt, either.
For details how ERROR_ACCESS_DENIED can be triggered, see
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858
Original-patch-by: Erik Faye-Lund <kusmabite@gmail.com> Initial-Test-By: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase--interactive: avoid empty list in shell for-loop
The $strategy_opts variable contains a space-separated list
of strategy options, each individually shell-quoted. To loop
over each, we "unwrap" them by doing an eval like:
eval '
for opt in '"$strategy_opts"'
do
...
done
'
Note the quoting that means we expand $strategy_opts inline
in the code to be evaluated (which is the right thing
because we want the IFS-split and de-quoting). If the
variable is empty, however, we ask the shell to eval the
following code:
for opt in
do
...
done
without anything between "in" and "do". Most modern shells
are happy to treat that like a noop, but reportedly ksh88 on
AIX considers it a syntax error. So let's catch the case
that the variable is empty and skip the eval altogether
(since we know the loop would be a noop anyway).
Reported-by: Armin Kunaschik <megabreit@googlemail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent update to Git LFS broke "git p4" by changing the output from
its "lfs pointer" subcommand.
* ls/p4-lfs:
git-p4: fix Git LFS pointer parsing
travis-ci: express Linux/OS X dependency versions more clearly
travis-ci: update Git-LFS and P4 to the latest version
wrap-for-bin.sh: regenerate bin-wrappers when switching branches
Commit e6e7530 (test helpers: move test-* to t/helper/ subdirectory -
2016-04-13) moves test-* to t/helper. However because bin-wrappers/*
only depend on wrap-for-bin.sh, when switching between a branch that has
this commit and one that does not, bin-wrappers/* may not be regenerated
and point to the old/outdated test programs.
This commit makes a non-functional change in wrap-for-bin.sh, just
enough for 'make' to detect and re-execute wrap-for-bin.sh. When
switching between a branch containing both this commit and e6e7530 and
one containing neither, bin-wrappers/*, we should get fresh bin-wrappers/*.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
9a001381 (Fix tests under GETTEXT_POISON on parseopt, 2012-08-27)
introduced check_i18n, but the helper was never used from the
beginning.
The same commit also introduced check_unknown_i18n to replace the
helper check_unknown and changed all users of the latter to use the
former, but failed to remove check_unknown itself.
But the only thing this test cares about is if "quiet: 3" is in the
output. We should be able to write the above 18 lines with just
four lines, like this:
test-parse-options: fix output when callback option fails
When test-parse-options detects an error on the command line, it
gives the usage string just like any parse-options API users do,
without showing any "variable dump". An exception is the callback
test, where a "variable dump" for the option is done before the
command line options are fully parsed.
Do not expose this implementation detail by separating the handling
of callback test into two phases, one to capture the fact that an
option was given during the option parsing phase, and the other to
show that fact as a part of normal "variable dump".
The effect of this fix is seen in the patch to t/t0040 where it
tried "test-parse-options --no-length" where "--length" is a callback
that does not take a negative form.
submodule: ensure that -c http.extraheader is heeded
To support this developer's use case of allowing build agents token-based
access to private repositories, we introduced the http.extraheader
feature, allowing extra HTTP headers to be sent along with every HTTP
request.
This patch verifies that we can configure these extra HTTP headers via the
command-line for use with `git submodule update`, too. Example: git -c
http.extraheader="Secret: Sauce" submodule update --init
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5551: make the test for extra HTTP headers more robust
To test that extra HTTP headers are passed correctly, t5551 verifies that
a fetch succeeds when two required headers are passed, and that the fetch
does not succeed when those headers are not passed.
However, this test would also succeed if the configuration required only
one header. As Apache's configuration is notoriously tricky (this
developer frequently requires StackOverflow's help to understand Apache's
documentation), especially when still supporting the 2.2 line, let's just
really make sure that the test verifies what we want it to verify.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lars Schneider noticed that the configuration introduced to test the
extra HTTP headers cannot be used with Apache 2.2 (which is still
actively maintained, as pointed out by Junio Hamano).
To let the tests pass with Apache 2.2 again, let's substitute the
offending <RequireAll> and `expr` by using old school RewriteCond
statements.
As RewriteCond does not allow testing for *non*-matches, we simply match
the desired case first and let it pass by marking the RewriteRule as
'[L]' ("last rule, do not process any other matching RewriteRules after
this"), and then have another RewriteRule that matches all other cases
and lets them fail via '[F]' ("fail").
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Tested-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose.
Add tests to check the behavior introduced by this commit and also to
verify that behavior of status doesn't break because of this commit.
Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even though a Git commit object is designed to be capable of storing
any binary data as its payload, in practice people use it to describe
the changes in textual form, and tools like "git log" are designed to
treat the payload as text.
Detect and warn when we see any commit object with a NUL byte in
it.
Note that a NUL byte in the header part is already detected as a
grave error. This change is purely about the message part.
There are a handful of incorrect "linkgit:<page>[<section>]"
instances in our documentation set.
* Some have an extra colon after "linkgit:"; fix them by removing
the extra colon;
* Some refer to a page outside the Git suite, namely curl(1); fix
them by using the `curl(1)` that already appears on the same page
for the same purpose of referring the readers to its manual page.
* Some spell the name of the page incorrectly, e.g. "rev-list" when
they mean "git-rev-list"; fix them.
* Some list the manual section incorrectly; fix them to make sure
they match what is at the top of the target of the link.
One test in t6036 prepares a file whose contents contain these
lines:
<<<<<<< Temporary merge branch 1
C
=======
B
>>>>>>> Temporary merge branch 2
and uses recursive merge strategy to run criss-cross merge with it.
Manual merge resolution by users fundamentally depends on being able
to distinguish the tracked contents from the separator lines added
by "git merge" in order to allow users to tell which block of lines
came from where. You can deliberately craft a file with lines that
resemble conflict marker lines to make it impossible for the user
(the outer merge of merge-recursive counts as a user of the result
of "virtual parent" merge) to tell which part is which, and write a
test to demonstrate that with such a file that "git merge" cannot
fundamentally work well and has to fail.
It however is pointless and waste of time and resource to run such a
test that asserts the obvious.
In real life, people who do need to track files with such lines that
have <<<< ==== >>>> as their prefixes set the conflict-marker-size
attribute to make sure they will be able to tell between the tracked
lines that happen to begin with these (confusing) prefixes and the
marker lines that are added by "git merge".
ll-merge: use a longer conflict marker for internal merge
The primary use of conflict markers is to help the user who resolves
the final (outer) merge by hand to show which part came from which
branch by separating the blocks of lines apart. When the conflicted
parts from a "virtual ancestor" merge created by merge-recursive
remains in the common ancestor part in the final result, however,
the conflict markers that are the same size as the final merge
become harder to see.
Increase the conflict marker size slightly for these inner merges so
that the markers from the final merge and cruft from internal merge
can be distinguished more easily.
This would help reduce the common issue that prevents "rerere" from
being used on a really complex conflict.
test-lib-functions.sh: rewrite test_seq without Perl
Rewrite the 'seq' imitation using only commands and features that
are typically found built into modern POSIX shells, instead of
relying on Perl to run a single-liner script.
88d50724 (am --skip: revert changes introduced by failed 3way merge,
2015-06-06), unlike all the other patches in the series, forgot to
quote the output from "$(git ls-files -u)" when using it as the
argument to "test -z", leading to a syntax error on platforms whose
test does not interpret "test -z" (no other arguments) as testing if
a string "-z" is the null string (which GNU test and test that is
built into bash and dash seem to do).
Note that $(git ls-files -u | wc -l) is deliberately left unquoted,
as some implementations of "wc -l" includes extra blank characters
in its output and cannot be compared as string, i.e. "test 0 = $(...)".
Signed-off-by: Armin Kunaschik <megabreit@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-lib-functions.sh: remove misleading comment on test_seq
We never used the "letters" form since we came up with "test_seq" to
replace use of non-portable "seq" in our test script, which we
introduced it at d17cf5f3 (tests: Introduce test_seq, 2012-08-04).
We use this helper to either iterate for N times (i.e. the values on
the lines do not even matter), or just to get N distinct strings
(i.e. the values on the lines themselves do not really matter, but
we care that they are different from each other and reproducible).
Stop promising that we may allow using "letters"; this would open an
easier reimplementation that does not rely on $PERL, if somebody
later wants to.