Switch all uses of $_z40 to $ZERO_OID so that they work correctly with
larger hashes. This commit was created by using the following sed
command to modify all files in the t directory except t/test-lib.sh:
sed -i 's/\$_z40/$ZERO_OID/g'
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Compared to 'test-chmtime -v +0 file' which prints the mtime and
and the file name, 'test-chmtime --get file' displays only the mtime.
If it is used in combination with (+|=|=+|=-|-)seconds, it changes
and prints the new value.
test-chmtime -v +0 file | sed 's/[^0-9].*$//'
is now equivalent to:
test-chmtime --get file
Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These two configuration variables are described in the documentation
to take an expiry period expressed in the number of days:
gc.rerereResolved::
Records of conflicted merge you resolved earlier are
kept for this many days when 'git rerere gc' is run.
The default is 60 days.
gc.rerereUnresolved::
Records of conflicted merge you have not resolved are
kept for this many days when 'git rerere gc' is run.
The default is 15 days.
There is no strong reason not to allow a more general "approxidate"
expiry specification, e.g. "5.days.ago", or "never".
Rename the config_get_expiry() helper introduced in the previous
step to git_config_get_expiry_in_days() and move it to a more
generic place, config.c, and use date.c::parse_expiry_date() to do
so. Give it an ability to allow the caller to tell among three
cases (i.e. there is no "gc.rerereResolved" config, there is and it
is correctly parsed into the *expiry variable, and there was an
error in parsing the given value). The current caller can work
correctly without using the return value, though.
In the future, we may find other variables that only allow an
integer that specifies "this many days" or other unit of time, and
when it happens we may need to drop "_days" suffix from the name of
the function and instead pass the "scale" value as another parameter.
But this will do for now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test creates a rerere database entry that is two days old, and
tries to expire with three different custom expiry configuration
(keep ones less than 5 days old, keep ones used less than 5 days
ago, and expire everything right now).
We'll be introducing a different way to spell the same "5 days" and
"right now" parameter in a later step; parameterize the test to make
it easier to test the new spelling when it happens.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move the "rerere gc with custom expiry" test up, so that it is close
to the existing basic "rerere gc" tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test blindly trusted that there may be _some_ entries left in
the rerere database, and used them by updating their timestamps to
see if the gc threshold variables are honoured correctly. This
won't work if there is no entry in the database when the test
begins.
Instead, clear the rerere database, and populate it with a few known
entries (which are bogus, but for the purpose of testing "garbage
collection", it does not matter---we want to make sure we collect
old cruft, even if the files are corrupt rerere database entries),
and use them for the expiry test.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "multiple identical conflicts" test counts the number of entries
in the rerere database after trying a handful of mergy operations
and recording their resolutions, but without initializing the rerere
database to a known state, allowing the state left by previous tests
to trigger a false failure. Make it robust by cleaning the database
before it starts.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because conflicts with the same contents inside conflict blocks
enclosed by "<<<<<<<" and ">>>>>>>" can now have multiple variants
to help three-way merge to adjust to the differences outside the
conflict blocks, "rerere forget $path" needs to be taught that there
may be multiple recorded resolutions that share the same conflict
hash (which groups the conflicts with "the same contents inside
conflict blocks"), among which there are some that would not be
relevant to the conflict we are looking at. These "other variants"
that happen to share the same conflict hash should not be cleared,
and the variant that would apply to the current conflict may not be
the zero-th one (which is the only one that is cleared by the
current code).
After finding the conflict hash, iterate over the existing variants
and try to resolve the conflict using each of them to find the one
that "cleanly" resolves the current conflict. That is the one we
want to forget and record the preimage for, so that the user can
record the corrected resolution.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adjust "git rerere gc" and "git rerere clear" to the new world order
with rerere database with multiple variants for the same shape of
conflicts.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This enables the multiple-variant support for real. Multiple
conflicts of the same shape can have differences in contexts where
they appear, interfering the replaying of recorded resolution of one
conflict to another, and in such a case, their resolutions are
recorded as different variants under the same conflict ID.
We still need to adjust garbage collection codepaths for this
change, but the basic "replay" functionality is functional with
this change.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the context of multiple identical conflicts are different, two
seemingly the same conflict resolution cannot be safely applied.
In such a case, at least we should be able to record these two
resolutions separately in the rerere database, and reuse them when
we see the same conflict later.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If by some accident there is only $GIT_DIR/rr-cache/$ID directory
existed, we wouldn't have recorded a preimage for a conflict that
is newly encountered, which would mean after a manual resolution,
we wouldn't have recorded it by storing the postimage, because the
logic used to be "if there is no rr-cache/$ID directory, then we are
the first so record the preimage". Instead, record preimage if we
do not have one.
In addition, if there is only $GIT_DIR/rr-cache/$ID/postimage
without corresponding preimage, we would have tried to call into
merge() and punted.
These would have been a situation frustratingly hard to recover
from.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is what the code intended.
No functional changes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As of the last commit, we can use "perl" instead of
"$PERL_PATH" when running tests, as the former is now a
function which uses the latter. As the shorter "perl" is
easier on the eyes, let's switch to using it everywhere.
This is not quite a mechanical s/$PERL_PATH/perl/
replacement, though. There are some places where we invoke
perl from a script we generate on the fly, and those scripts
do not have access to our internal shell functions. The
result can be double-checked by running:
ln -s /bin/false bin-wrappers/perl
make test
which continues to pass even after this patch.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the i18n-specific test functions in test scripts for parseopt tests.
This issue was was introduced in v1.7.10.1-488-g54e6d:
54e6d i18n: parseopt: lookup help and argument translations when showing usage
and been broken under GETTEXT_POISON=YesPlease since.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise it will be split at a space after "Program" when it is set
to "\\Program Files\perl" or something silly like that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
GIT-BUILD-OPTIONS defines PERL_PATH to be used in the test suite. Only a
few tests already actually use this variable when perl is needed. The
other test just call 'perl' and it might happen that the wrong perl
interpreter is used.
This becomes problematic on Windows, when the perl interpreter that is
compiled and installed on the Windows system is used, because this perl
interpreter might introduce some unexpected LF->CRLF conversions.
This patch makes sure that $PERL_PATH is used everywhere in the test suite
and that the correct perl interpreter is used.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/merge-renormalize:
merge-recursive --renormalize
rerere: never renormalize
rerere: migrate to parse-options API
t4200 (rerere): modernize style
ll-merge: let caller decide whether to renormalize
ll-merge: make flag easier to populate
Documentation/technical: document ll_merge
merge-trees: let caller decide whether to renormalize
merge-trees: push choice to renormalize away from low level
t6038 (merge.renormalize): check that it can be turned off
t6038 (merge.renormalize): try checkout -m and cherry-pick
t6038 (merge.renormalize): style nitpicks
Don't expand CRLFs when normalizing text during merge
Try normalizing files to avoid delete/modify conflicts when merging
Avoid conflicts when merging branches with mixed normalization
Conflicts:
builtin/rerere.c
t/t4200-rerere.sh
Guard all test code with test_expect_success to make the
script easier to follow. While at it, pick some other nits:
- use test_tick (more than we have to, to be realistic);
- 'single quotes' and \escaped HERE documents where possible
simplify review for escaping problems;
- omit whitespace after >redirection operators for
consistency with other tests;
- use "update-index --refresh" instead of testing that
"ls-files -u" output is empty, since the former produces
nicer output on failure;
- compare to expected nonempty "ls-files -u" output instead
of counting lines when it is expected to be nonempty.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'rerere gc' prunes resolutions of conflicted merges that occurred long
time ago, and when doing so it takes the creation time of the
conflicted automerge results into account. This can cause the loss of
frequently used conflict resolutions (e.g. long-living topic branches
are merged into a regularly rebuilt integration branch (think of git's
pu)) when they become old enough to exceed 'rerere gc's threshold.
To prevent the loss of valuable merge resolutions 'rerere' will (1)
update the timestamp of the recorded conflict resolution (i.e.
'postimage') each time when encountering and resolving the same merge
conflict, and (2) take this timestamp, i.e. the time of the last usage
into account when gc'ing.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Several tests did not use test_expect_success for their setup
commands. Putting these start commands into the testing framework
means both that errors during setup will be caught quickly and that
non-error text will be suppressed without -v.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a command line option to override rerere.autoupdate configuration
variable to make it more useful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
POSIX only requires sed to work on text files and MERGE_RR is not a text
file. Some versions of sed complain that this file is not newline
terminated, and exit non-zero. Use perl instead which does not have a
problem with it.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These two lines appear to be unnecessary. They set variables which are not
used afterwards. The primary motivation to remove them is that the sed
invocation exits non-zero for seds which require newline termination of
input files.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sb/dashless:
Make usage strings dash-less
t/: Use "test_must_fail git" instead of "! git"
t/test-lib.sh: exit with small negagive int is ok with test_must_fail
Conflicts:
builtin-blame.c
builtin-mailinfo.c
builtin-mailsplit.c
builtin-shortlog.c
git-am.sh
t/t4150-am.sh
t/t4200-rerere.sh
This patch changes every occurrence of "! git" -- with the meaning
that a git call has to gracefully fail -- into "test_must_fail git".
This is useful to
- make sure the test does not fail because of a signal,
e.g. SIGSEGV, and
- advertise the use of "test_must_fail" for new tests.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you want to reuse the rerere cache in another repository, and set
a symbolic link to it, you do not want to have the two repositories
interfer with each other by accessing the _same_ MERGE_RR.
For example, if you use contrib/git-new-workdir to set up a second
working directory, and you have a conflict in one working directory,
but commit in the other working directory first, the wrong "resolution"
will be recorded.
The easy solution is to move MERGE_RR out of the rr-cache/ directory,
which also corresponds with the notion that rr-cache/ contains cached
resolutions, not some intermediate temporary states.
Noticed by Kalle Olavi Niemitalo.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a conflicting file contains a line that begin with "=======", rerere
failed to parse conflict markers. This result to a wrong preimage file and
an unexpected error for the user. The boundary between ours and theirs
not just begin with 7 equals, but is followed by either a SP or a LF.
This patch enforces parsing rules so that markers match in the right order,
and when ambiguous, the command does not autoresolve the conflicted file.
Especially because we are introducing rerere.autoupdate configuration
(which is off by default for safety) that automatically stages the
resolution made by rerere, it is necessary to make sure that we do not
autoresolve when there is any ambiguity.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test used "diff-files -q" which is not about reporting if there is
a difference at all. Instead, make sure that the path remains as
conflicting in the index after rerere autoresolves it, as we will be
adding rerere.autoupdate configuration with the next patch.
As a general principle, we should not use "git diff" to validate the
results of what git command that is being tested has done. We would not
know if we are testing the command in question, or locating a bug in the
cute hack of "git diff --no-index".
Rather use test_cmp for that purpose.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Dealing with NULs is not always safe with tr. On Solaris,
incoming NULs are silently deleted by both the System V and
UCB versions of tr. When converting to NULs, the System V
version works fine, but the UCB version silently ignores the
request to convert the character.
This patch changes all instances of tr using NULs to use
"perl -pe 'y///'" instead.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some versions of 'tr' only accept octal codes if entered with three digits,
and therefor misinterpret the '\0' in the test suite.
Some versions of 'tr' reject the (needless) use of character classes.
Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Two-file merges were rare enough that they were dropped outside of the
radar. This fix is a trivial change to builtin-rerere.c::find_conflict().
It is still sane to insist that we do not do rerere for symlinks, and
require to have stages #2 and #3, but we can drop the requirement to have
stage #1. rerere does not use information from there anyway.
This fix is from Junio, together with two tests to verify that it works
as expected.
Acked-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, "git rerere" was enabled by creating the directory
.git/rr-cache. That is definitely not in line with most other
features, which are enabled by a config variable.
So, check the config variable "rerere.enabled". If it is set
to "false" explicitely, do not activate rerere, even if
.git/rr-cache exists. This should help when you want to disable
rerere temporarily.
If "rerere.enabled" is not set at all, fall back to detection
of the directory .git/rr-cache.
[jc: with minimum tweaks]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix t4200 so that it also works on OS X by not relying on gnu
extensions to sed.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier code does not swap hunks when the beginning of the
first side is identical to the whole of the second side. In
such a case, the first one should sort later.
Signed-off-by: Junio C Hamano <junkio@cox.net>
On OS X, wc outputs 6 spaces before the number of lines, so the test
expecting the string "10" failed. Do not quote $cmd to strip away
the problematic whitespace as other tests do.
Also fix the grammar of the test name while making changes to it.
There's only one preimage, so it's "has", not "have".
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a file has more then one conflicting hunks, it repeated the
contents of previous hunks in output for later ones.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that "git diff" handles stdin and relative paths outside the
working tree correctly, we can convert all instances of "diff -u"
to "git diff".
This commit is really the result of
$ perl -pi.bak -e 's/diff -u/git diff/' $(git grep -l "diff -u" t/)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from commit c699a40d68215c7e44a5b26117a35c8a56fbd387)
test-lib:
Make sure test-chmtime has been built before starting.
t4200-rerere:
Removed non-portable date dependency and avoid touch
Avoid "test -a" which isn't portable, either
lib-git-svn:
Use test-chmtime instead of Perl one-liner to poke
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Quite nonstandard "date -d @11111111 +%s" does not even fail on
OpenBSD but gives the current date in "seconds since epoch"
format, which is useless for the purpose of this test. We want
to make sure that this returns exactly the same input before
proceeding.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Non-GNU touch do not have the -d option to take free form
date strings. The POSIX -t option should be more widespread.
For this to work, date needs to output YYYYMMDDHHMM.SS date strings.
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
