In 3bf78867 (test-lib: Let tests specify commands to be run at end of
test, 2010-05-02), the git test harness learned to run cleanup
commands unconditionally at the end of a test.  During each test,
the intended cleanup actions are collected in the test_cleanup variable
and evaluated.  That variable looks something like this:

	eval_ret=$?; clean_something && (exit "$eval_ret")
	eval_ret=$?; clean_something_else && (exit "$eval_ret")
	eval_ret=$?; final_cleanup && (exit "$eval_ret")
	eval_ret=$?

All cleanup actions are run unconditionally but if one of them fails
it is properly reported through $eval_ret.

On FreeBSD, unfortunately, $? is set at the beginning of an ‘eval’
to 0 instead of the exit status of the previous command.  This results
in tests using test_expect_code appearing to fail and all others
appearing to pass, unless their cleanup fails.  Avoid the problem by
setting eval_ret before the ‘eval’ begins.

Thanks to Jeff King for the explanation.

Cc: Jeff King <peff@peff.net>
Cc: Johannes Sixt <j6t@kdbg.org>
Acked-by: NJeff King <peff@peff.net>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Certain actions can imply that if the test fails early, recovery from
within other tests is too much to expect:

 - creating unwritable directories, like the EACCESS test in t0001-init
 - setting unusual configuration, like user.signingkey in t7004-tag
 - crashing and leaving the index lock held, like t3600-rm once did

Some test scripts work around this by running cleanup actions outside
the supervision of the test harness, with the unfortunate consequence
that those commands are not appropriately echoed and their output not
suppressed.  Others explicitly save exit status, clean up, and then
reset the exit status within the tests, which has excellent behavior
but makes the tests hard to read.  Still others ignore the problem.

Allow tests a fourth option: by calling this function, tests can
stack up commands they would like to be run to clean up.

Commands passed to test_when_finished during a test are
unconditionally run in the test environment immediately before the
test is completed, in last-in-first-out order.  If some cleanup
command fails, then the other cleanup commands are still run before
the failure is reported and the test script allowed to continue.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently, a local git clone reports only initializing an empty
git dir, which is potentially confusing.

Instead, report that cloning is in progress and when it is done
(unless -q) is given, and suppress the init report.
Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Dear Junio,

this is a resend of relicensing patch for test suite library, which
was initially sent by Carl Worth. Since the time you sent me acks for
this patch collected by you, I collected 8 additional acks as is
documented at
https://git.wiki.kernel.org/index.php/Test-lib_reclicensing. There are
still three contributors missing: Bert Wesarg, Stephan Beyer and Bryan
Donlan. The contributions of first two are clearly not copyrightable.
I'm not sure about the copyrightability of Bryan Donlan's
contributions (git log -p --author='Bryan Donlan' t/test-lib.sh).

Carl told me that in your ack collection process you missed only three
acks. So I wonder whether you already did some analysis of which
contributions are copyrightable. If so, are the missing acks in the
list bellow?

Thanks
Michal

8<--------8<--------8<--------
This file has had no explicit license information noted in it, but
has clearly been created and modified according to the terms of GPLv2
as with the rest of the git code base.

The purpose of relicensing is to allow other GPLv3+ projects (in
particular, the notmuch project: http://notmuchmail.org) to use this
same test-suite structure and to contribute changes back as well.
Signed-off-by: NCarl Worth <cworth@cworth.org>
Signed-off-by: NMichal Sojka <sojkam1@fel.cvut.cz>
Acked-by: NAlex Riesen <raa.lkml@gmail.com>
Acked-by: NBrandon Casey <drafnel@gmail.com>
Acked-by: NClemens Buchacher <drizzd@aon.at>
Acked-by: NDavid Reiss <dreiss@facebook.com>
Acked-by: NEmil Sit <sit@emilsit.net>
Acked-by: NEric Wong <normalperson@yhbt.net>
Acked-by: NFredrik Kuivinen <frekui@gmail.com>
Acked-by: NGerrit Pape <pape@smarden.org>
Acked-by: NChristian Couder <chriscool@tuxfamily.org>
Acked-by: NJakub Narebski <jnareb@gmail.com>
Acked-by: NJeff King <peff@peff.net>
Acked-by: NJohan Herland <johan@herland.net>
Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Acked-by: NJohannes Sixt <j6t@kdbg.org>
Acked-by: NJonathan Nieder <jrnieder@gmail.com>
Acked-by: NJosh Triplett <josh@joshtriplett.org>
Acked-by: NJunio C Hamano <gitster@pobox.com>
Acked-by: NLea Wiemann <lewiemann@gmail.com>
Acked-by: NMarkus Heidelberg <markus.heidelberg@web.de>
Acked-by: NMartin Waitz <tali@admingilde.org>
Acked-by: NMatthew Ogilvie <mmogilvi_git@miniinfo.net>
Acked-by: NMatthias Lederhofer <matled@gmx.net>
Acked-by: NMichael J Gruber <git@drmicha.warpmail.net>
Acked-by: NMichele Ballabio <barra_cuda@katamail.com>
Acked-by: NMiklos Vajna <vmiklos@frugalware.org>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Acked-by: NPavel Roskin <proski@gnu.org>
Acked-by: NPetr Baudis <pasky@ucw.cz>
Acked-by: NPierre Habouzit <madcoder@debian.org>
Acked-by: NRobin Rosenberg <robin.rosenberg@dewire.com>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Acked-by: NStephen Boyd <bebarino@gmail.com>
Acked-by: NSverre Rabbelier <srabbelier@gmail.com>
Acked-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently, there are 6 tests which are not even written but are
'test_expect_failure message false'.
Do not abuse test_expect_failure as a to do marker, but mark them as
'#TODO' instead.
Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net>
Acked-by: NNguyen Thai Ngoc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMatthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The last two tests here were always supposed to fail in the sense
that, according to code and documentation, mktree should read non-recursive
ls-tree output, but not recursive one, and therefore explicitely refuses
to deal with slashes.

Adjust the test (must_fail) so that it succeeds when mktree dies on
slashes.
Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Consider an evil merge of two commits A and B, both of which have a
file 'foo', but the merge result does not have that file.

The combined-diff code learned in 4462731e (combine-diff: do not punt
on removed or added files., 2006-02-06) to concisely show only the
removal, since that is the evil part and the previous contents are
presumably uninteresting.

However, to diagnose an empty merge result, it overloaded the variable
that holds the file's length.  This means that the check also triggers
for truncated files.  Consequently, such files were not shown in the
diff at all despite the merge being clearly evil.

Fix this by adding a new variable that distinguishes whether the file
was deleted (which is the case 4462731e handled) or truncated.  In the
truncated case, we show the full combined diff again, which is rather
spammy but at least does not hide the evilness.
Reported-by: NDavid Martínez Martí <desarrollo@gestiweb.com>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The simple test for an existing .git directory gives an incorrect result
if .git is a file that records "gitdir: overthere". So for submodules that
use a .git file, "git status" and the diff family - when the "--submodule"
option is given - did assume the submodule was not populated at all when
a .git file was used, thus generating wrong output or no output at all.

This is fixed by using read_gitfile_gently() to get the correct location
of the .git directory. While at it, is_submodule_modified() was cleaned up
to use the "dir" member of "struct child_process" instead of setting the
GIT_WORK_TREE and GIT_DIR environment variables.
Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Don't output an error on `git format-patch --ignore-if-in-upstream HEAD`.
This matches the behavior of `git format-patch HEAD`.
Signed-off-by: NKevin Ballard <kevin@sb.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The notes code intends to write reflog entries, but currently they are
not written because log_ref_write() checks for the refname path
explicitly.

Add refs/notes to the list of allowed paths so that notes references are
treated just like branch heads, i.e. according to core.logAllRefUpdates
and core.bare.
Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net>
Acked-by: NJohan Herland <johan@herland.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Test whether the notes code writes reflog entries. It intends to
(setting up the reflog messages) but currently does not.
Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net>
Acked-by: NJohan Herland <johan@herland.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The post-rewrite support, in the form of the call to
'record_in_rewritten', was hidden in the arm where we have to record a
new commit for the user.  This meant that it was never invoked in the
case where the user has already amended the commit by herself.

[The test is designed to exercise both arms of the 'if' in question.]

Furthermore, recording the stopped-sha (the SHA1 of the commit before
the editing) suffered from a cut&paste error from die_with_patch and
used the wrong variable, hence it never recorded anything.

Noticed by Junio.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Upon failure of any of these tests (or when a test that is marked as
expecting a failure is fixed), we will end up running later tests in
random places.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When diff.guitool is unconfigured and "--gui" is specified
git-difftool dies with the following error message:

	config diff.guitool: command returned error: 1

Catch the error so that the "--gui" flag is a no-op when
diff.guitool is unconfigured.
Signed-off-by: NDavid Aguilar <davvid@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add some more tests so we don't break behavior upon modernizing
fmt-merge-msg.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This test defines its own version of test_tick. Get rid of it.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When FETCH_HEAD contains only 'not-for-merge' entries fmt-merge-msg
still outputs "Merge" (and if the branch isn't master " into <branch>").
In this case fmt-merge-msg is outputting junk and should really just
be quiet. Fix it.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

For git-rebase.sh, --no-ff is a synonym for --force-rebase.

For git-rebase--interactive.sh, --no-ff cherry-picks all the commits in
the rebased branch, instead of fast-forwarding over any unchanged commits.

--no-ff offers an alternative way to deal with reverted merges.  Instead of
"reverting the revert" you can use "rebase --no-ff" to recreate the branch
with entirely new commits (they're new because at the very least the
committer time is different).  This obviates the need to revert the
reversion, as you can re-merge the new topic branch directly.  Added an
addendum to revert-a-faulty-merge.txt describing the situation and how to
use --no-ff to handle it.
Signed-off-by: NMarc Branchaud <marcnarc@xiplink.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

55246aac (Dont use "<unknown>" for placeholders and suppress printing
of empty user formats) introduced a check to prevent empty
user-formats from being printed. This test didn't take empty commit
messages into account, and prevented the line-termination from being
output. This lead to multiple commits on a single line.

Correct it by guarding the check with a check for user-format. A
similar correction for the --graph code-path has been included.
Signed-off-by: NErik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When writing conflict hunks in ‘diff3 -m’ format, also add a label to
the common ancestor.  Especially in a cherry-pick, it is not immediately
obvious without such a label what the common ancestor represents.

git rerere does not have trouble parsing the new output and its preimage
ids are unchanged since it includes its own code for recreating conflict
hunks.  No other code in git parses conflict hunks.
Requested-by: NStefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When reverting a commit, the commit being merged is not the commit
to revert itself but its parent.  Add “parent of” to the conflict
hunk label to make this more clear.

The conflict hunk labels are all pieces of a single string written in
the new get_message() function.  Avoid some complication by using
mempcpy to advance a pointer as the result is written.

Also free the corresponding temporary buffer (it was leaked before).
This is not important because it is a small one-time allocation.  It
would become a memory leak if unnoticed when libifying revert.

This patch uses calls to strlen() instead of integer constants in some
places.  GCC will compute the length at compile time; I am not sure
about other compilers, but this is not performance-critical anyway.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git checkout --merge --conflict=diff3 can be used to present conflict
hunks including text from the common ancestor.  The added information
is helpful for resolving a merge by hand, and merge tools tend to
understand it because it is very similar to what ‘diff3 -m’ produces.

Unlike current git, diff3 -m includes a label for the merge base on
the ||||||| line, and unfortunately, some tools cannot parse the
conflict hunks without it.  Humans can benefit from a cue when
learning to interpreting the format, too.  Mark the start of the text
from the old branch with a label based on the branch’s name.

git rerere does not have trouble parsing this output and its preimage
ids are unchanged since it includes its own code for recreating
conflict hunks.  No other code in git tries to parse conflict hunks.
Requested-by: NStefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git checkout --conflict=diff3 can be used to present conflicts hunks
including text from the common ancestor:

	<<<<<<< ours
	ourside
	|||||||
	original
	=======
	theirside
	>>>>>>> theirs

The added information is helpful for resolving a merge by hand, and
merge tools can usually understand it without trouble because it looks
like output from ‘diff3 -m’.

diff3 includes a label for the merge base on the ||||||| line, and it
seems some tools (for example, Emacs 22’s smerge-mode) cannot parse
conflict hunks without such a label.  Humans could use help in
interpreting the output, too.  So change the marker for the start of the
text from the common ancestor to include the label “base”.

git rerere’s conflict identifiers are not affected: to parse conflict
hunks, rerere looks for whitespace after the ||||||| marker rather
than a newline, and to compute preimage ids, rerere has its own code
for creating conflict hunks.  No other code in git tries to parse
conflict hunks.
Requested-by: NStefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git merge-file --diff3 can be used to present conflicts hunks
including text from the common ancestor.

The added information is helpful for resolving a merge by hand, and
merge tools can usually grok it because it looks like output from
diff3 -m.  However, ‘diff3’ includes a label for the merge base on the
||||||| line and some tools cannot parse conflict hunks without such a
label.  Write the base-name as passed in a -L option (or the name of
the ancestor file by default) on that line.

git rerere will not have trouble parsing this output, since instead of
looking for a newline, it looks for whitespace after the |||||||
marker.  Since rerere includes its own code for recreating conflict
hunks, conflict identifiers are unaffected.  No other code in git tries
to parse conflict hunks.
Requested-by: NStefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We are about to change the format of the conflict hunks that
cherry-pick and revert write.  Add tests checking the current behavior
first.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We are about to change the format of the conflict hunks that ‘checkout
--merge’ writes.  Add tests checking the current behavior first.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio 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: NBrian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This test is supposed to check that git-remote correctly refuses to delete
all URLS for the specified remote which match the '.*' regular expression.
Since the '*' was not protected, it was interpreted by the shell as a file
glob and expanded before being passed to git-remote.  The call to
git-remote still exited non-zero in this case, and the overall test still
passed, but it exited non-zero because git-remote was passed the incorrect
number of arguments, not for the reason it was supposed to fail.

Correct the test by escaping the '*'.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Solaris only uses one colon in the listing of the ACL mask, Linux uses two,
so substitute egrep for grep and make the second colon optional.

The -q option for Solaris 7's /usr/xpg4/bin/egrep does not appear to be
implemented, so redirect output to /dev/null.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some implementations of setfacl do not recalculate the effective rights
mask when the ACL is modified.  So, set the effective rights mask
explicitly to ensure that the ACL's that are set on the directories will
have effect.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This test was using the group read permission bit as an indicator of the
default ACL mask.  This behavior is valid on Linux but not on other
platforms like Solaris.  So, rather than looking at mode bits, just test
readability for the user.  This, along with the checks for the existence
of the ACL's that were set on the parent directories, should be enough.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

According to the Linux setfacl man page, in order for an ACL to be valid,
the following rules must be satisfied:

   * Whenever an ACL contains any Default ACL entries, the three Default
     ACL base entries (default owner, default group, and default others)
     must also exist.

   * Whenever a Default ACL contains named user entries or named group
     objects, it must also contain a default effective rights mask.

Some implementations of setfacl (Linux) do this automatically when
necessary, some (Solaris) do not.  Solaris's setfacl croaks when trying to
create a default user ACL if the above rules are not satisfied.  So, create
them before modifying the default user ACL's.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some platforms (Solaris) have a setfacl whose -d switch works differently
than the one on Linux.  On Linux, it causes all operations to be applied
to the Default ACL.  There is a notation for operating on the Default ACL:

   [d[efault]:] [u[ser]:]uid [:perms]

so use it instead of the -d switch.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Brandon Casey noticed that t5505 had accidentally broken its && chain,
hiding inconsistency between the code that writes the warning to the
standard output and the test that expects to see the warning on the
standard error, which was introduced by f8948e2f (remote prune: warn
dangling symrefs, 2009-02-08).

It turns out that the issue is deeper than that.  After f8948e2f, a symref
that is dangling is marked with a NULL sha1, and the idea of using NULL
sha1 to mean a deleted ref was scrapped, but somehow a follow-up eafb4526
(do_one_ref(): null_sha1 check is not about broken ref, 2009-07-22)
incorrectly reorganized do_one_ref(), still thinking NULL sha1 is never
used in the code.

Fix this by:

 - adopt Brandon's fix to t5505 test;

 - introduce REF_BROKEN flag to mark a ref that fails to resolve (dangling
   symref);

 - move the check for broken ref back inside the "if we are skipping
   dangling refs" code block.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>