This moves the call to git_config to a place where it doesn't break the
logic for using git archive in a bare repository but retains the fix to
make git archive respect core.autocrlf.
Tests are by René Scharfe.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Tested-by: Deskin Miller <deskinm@umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Till now --no-deref was just ignored when deleting refs, fix this.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This had two problems with symrefs. First, it copied the actual sha1
instead of the "pointer", second it failed to remove the old ref after a
successful rename.
Given that till now delete_ref() always dereferenced symrefs, a new
parameters has been introduced to delete_ref() to allow deleting refs
without a dereference.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This diff is meant for human consumption, so it makes sense
to apply text conversion here, as we would for the regular
diff porcelain.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These tests provide a basic sanity check that textconv'd
files work. The tests try to describe how this configuration
_should_ work; thus some of the tests are marked to expect
failure.
In particular, we fail to actually textconv anything because
the 'diff.foo.binary' config option is not set, which will
be fixed in the next patch.
This also means that some "expect_failure" tests actually
seem to be fixed; in reality, this is just because textconv
is broken and its failure mode happens to make these tests
work.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git status -v" shows a diff, we did not respect the
user's usual diff preferences at all. Loading just
git_diff_basic_config would give us things like rename
limits and diff drivers. But it makes even more sense to
load git_diff_ui_config, which gives us colorization if the
user has requested it.
Note that we need to take special care to cancel
colorization when writing to the commit template file, as
described in the code comments.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We treat symlinks as text containing the results of the
symlink, so it doesn't make much sense to text-convert them.
Similarly gitlink components just end up as the text
"Subproject commit $sha1", which we should leave intact.
Note that a typechange may be broken into two parts: the
removal of the old part and the addition of the new. In that
case, we _do_ show the textconv for any part which is the
addition or removal of a file we would ordinarily textconv,
since it is purely acting on the file contents.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffs that have been produced with textconv almost certainly
cannot be applied, so we want to be careful not to generate
them in things like format-patch.
This introduces a new diff options, ALLOW_TEXTCONV, which
controls this behavior. It is off by default, but is
explicitly turned on for the "log" family of commands, as
well as the "diff" porcelain (but not diff-* plumbing).
Because both text conversion and external diffing are
controlled by these diff options, we can get rid of the
"plumbing versus porcelain" distinction when reading the
config. This was an attempt to control the same thing, but
suffered from being too coarse-grained.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original implementation of textconv put the conversion
into fill_mmfile. This was a bad idea for a number of
reasons:
- it made the semantics of fill_mmfile unclear. In some
cases, it was allocating data (if a text conversion
occurred), and in some cases not (if we could use the
data directly from the filespec). But the caller had
no idea which had happened, and so didn't know whether
the memory should be freed
- similarly, the caller had no idea if a text conversion
had occurred, and so didn't know whether the contents
should be treated as binary or not. This meant that we
incorrectly guessed that text-converted content was
binary and didn't actually show it (unless the user
overrode us with "diff.foo.binary = false", which then
created problems in plumbing where the text conversion
did _not_ occur)
- not all callers of fill_mmfile want the text contents. In
particular, we don't really want diffstat, whitespace
checks, patch id generation, etc, to look at the
converted contents.
This patch pulls the conversion code directly into
builtin_diff, so that we only see the conversion when
generating an actual patch. We also then know whether we are
doing a conversion, so we can check the binary-ness and free
the data from the mmfile appropriately (the previous version
leaked quite badly when text conversion was used)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 9441b61dc5 introduced serious bugs in index-pack which are
described and fixed by commit ce3f6dc655. However, despite the
boldness of those bugs, the test suite still passed.
This improves t5302-pack-index.sh so to ensure a much better code
path coverage. With commit ce3f6dc655 reverted, 17 of the 26 tests
do fail now.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, branches were listed on a single line in each section. But
if there are many branches, then horizontal, line-wrapped lists are very
inconvenient to scan for a human. This makes the lists vertical, i.e one
branch per line is printed.
Since "git remote" is porcelain, we can easily make this
backwards-incompatible change.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a file is different between the working tree copy, the index, and the
HEAD, then we do not allow it to be deleted without --force.
However, this is overly tight in the face of "git add --intent-to-add":
$ git add --intent-to-add file
$ : oops, I don't actually want to stage that yet
$ git rm --cached file
error: 'empty' has staged content different from both the
file and the HEAD (use -f to force removal)
$ git rm -f --cached file
Unfortunately, there is currently no way to distinguish between an empty
file that has been added and an "intent to add" file. The ideal behavior
would be to disallow the former while allowing the latter.
This patch loosens the safety valve to allow the deletion only if we are
deleting the cached entry and the cached content is empty. This covers
the intent-to-add situation, and assumes there is little harm in not
protecting users who have legitimately added an empty file. In many
cases, the file will still be empty, in which case the safety valve does
not trigger anyway (since the content remains untouched in the working
tree). Otherwise, we do remove the fact that no content was staged, but
given that the content is by definition empty, it is not terribly
difficult for a user to recreate it.
However, we still document the desired behavior in the form of two
tests. One checks the correct removal of an intent-to-add file. The other
checks that we still disallow removal of empty files, but is marked as
expect_failure to indicate this compromise. If the intent-to-add feature
is ever extended to differentiate between normal empty files and
intent-to-add files, then the safety valve can be re-tightened.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/diff-convfilter:
diff: add filter for converting binary to text
diff: introduce diff.<driver>.binary
diff: unify external diff and funcname parsing code
t4012: use test_cmp instead of cmp
* js/maint-fetch-update-head:
pull: allow "git pull origin $something:$current_branch" into an unborn branch
Fix fetch/pull when run without --update-head-ok
Conflicts:
t/t5510-fetch.sh
* jc/maint-co-track:
Enhance hold_lock_file_for_{update,append}() API
demonstrate breakage of detached checkout with symbolic link HEAD
Fix "checkout --track -b newbranch" on detached HEAD
Conflicts:
builtin-commit.c
Currently git-blame outputs text from the commit messages
(e.g. the author name and the summary string) as-is, without
even providing any information about the encoding used for
the data. It makes interpreting the data in multilingual
environment very difficult.
This commit changes the blame implementation to recode the
messages using the rules used by other commands like git-log.
Namely, the target encoding can be specified through the
i18n.commitEncoding or i18n.logOutputEncoding options, or
directly on the command line using the --encoding parameter.
Converting the encoding before output seems to be more
friendly to the porcelain tools than simply providing the
value of the encoding header, and does not require changing
the output format.
If anybody needs the old behavior, it is possible to
achieve it by specifying --encoding=none.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before commit d0b92a3f6e it was possible to run 'git index-pack'
directly in the .git/objects/pack/ directory. Restore that ability.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
06cbe855 (Make core.sharedRepository more generic, 2008-04-16) made
several testcases in t1301-shared-repo.sh which fail if on a system
which creates files with extended attributes (e.g. SELinux), since ls
appends a '+' sign to the permission set in such cases. In fact,
POSIX.1 allows ls to add a single printable character after the usual
3x3 permission bits to show that an optional alternate/additional access
method is associated with the path.
This fixes the testcase to strip any such sign prior to verifying the
permission set.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tested-by: Deskin Miller <deskinm@umich.edu>
* dp/checkattr:
git-check-attr(1): use 'verse' for multi-line synopsis sections
check-attr: Add --stdin option
check-attr: add an internal check_attr() function
This changes the "die_on_error" boolean parameter to a mere "flags", and
changes the existing callers of hold_lock_file_for_update/append()
functions to pass LOCK_DIE_ON_ERROR.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When core.prefersymlinkrefs is in use, detaching the HEAD by
checkout incorrectly clobbers the tip of the current branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When aborting a failed merge that has brought in a new path using "git
reset --hard" or "git read-tree --reset -u", we used to first forget about
the new path (via read_cache_unmerged) and then matched the working tree
to what is recorded in the index, thus ending up leaving the new path in
the work tree.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes erroneous output slightly easier to see. We also
flip the argument order to match our usual style.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
format-patch is most commonly used for multiple patches at once when
sending a patchset, in which case we want to number the patches; on
the other hand, single patches are not usually expected to be
numbered.
In other words, the typical behavior expected from format-patch is the
one obtained by enabling autonumber, so we set it to be the default.
Users that want to disable numbering for a particular patchset can do
so with the existing -N command-line switch. Users that want to
change the default behavior can use the format.numbering config key.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Test-updates-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test to make sure that checkout fails when --track was asked for and
we cannot set up tracking information in t7201 was wrong, and it turns out
that the implementation for that feature itself was buggy. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the "git status" display code was originally converted
to C, we copied the code from ls-files to discover whether a
pathname returned by read_directory was an "other", or
untracked, file.
Much later, 5698454e updated the code in ls-files to handle
some new cases caused by gitlinks. This left the code in
wt-status.c broken: it would display submodule directories
as untracked directories. Nobody noticed until now, however,
because unless status.showUntrackedFiles was set to "all",
submodule directories were not actually reported by
read_directory. So the bug was only triggered in the
presence of a submodule _and_ this config option.
This patch pulls the ls-files code into a new function,
cache_name_is_other, and uses it in both places. This should
leave the ls-files functionality the same and fix the bug
in status.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the caller supplies --tags they want the lightweight, unannotated
tags to be searched for a match. If a lightweight tag is closer
in the history, it should be matched, even if an annotated tag is
reachable further back in the commit chain.
The same applies with --all when matching any other type of ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-By: Uwe Kleine-König <ukleinek@strlen.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 969c8775 introduced a test which uses the non-portable construct:
command1 && ! command2 | command3
which must be
command1 && ! (command2 | command3)
to work on bsd shells (this is another example of bbf08124, which fixed
several similar cases).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some misguided documents floating on the Net suggest this sequence:
mkdir newdir && cd newdir
git init
git remote add origin $url
git pull origin master:master
"git pull" has known about misguided "pull" that lets the underlying fetch
update the current branch for a long time. It also has known about
"git pull origin master" into a branch yet to be born.
These two workarounds however were not aware of the existence of each
other and did not work well together. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
t1301-shared-repo.sh: don't let a default ACL interfere with the test
git-check-attr(1): add output and example sections
xdiff-interface.c: strip newline (and cr) from line before pattern matching
t4018-diff-funcname: demonstrate end of line funcname matching flaw
t4018-diff-funcname: rework negated last expression test
Typo "does not exists" when git remote update remote.
remote.c: correct the check for a leading '/' in a remote name
Add testcase to ensure merging an early part of a branch is done properly
Conflicts:
t/t7600-merge.sh
This test creates files with several different umasks and expects their
permissions to be initialized according to the umask, so a default ACL on the
trash directory (which overrides the umask for files created in that directory)
causes the test to fail. To avoid that, remove the default ACL if possible with
setfacl(1).
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This seems like the best guess we can make until git sequencer marks are
available. That being said, within the context of re-ordering a commit before
its parent in todo, I think applying it on top of the current commit seems like
a reasonable assumption of what the user intended.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The first case was based off a script from Avi Kivity <avi@redhat.com>.
The second case includes a merge-of-a-merge to ensure both are included in todo.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
`rebase -i -p` got its rev-list of commits to keep by --left-right and
--cherry-pick. Adding --cherry-pick would drop commits that duplicated changes
already in the rebase target.
The dropped commits were then forgotten about when it came to rewriting the
parents of their descendents, so the descendents would get cherry-picked with
their old, unwritten parents and essentially make the rebase a no-op.
This commit adds a $DOTEST/dropped directory to remember dropped commits and
rewrite their children's parent as the dropped commit's possibly-rewritten
first-parent.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
POSIX doth sayeth:
"In the regular expression processing described in IEEE Std 1003.1-2001,
the <newline> is regarded as an ordinary character and both a period and
a non-matching list can match one. ... Those utilities (like grep) that
do not allow <newline>s to match are responsible for eliminating any
<newline> from strings before matching against the RE."
Thus far git has not been removing the trailing newline from strings matched
against regular expression patterns. This has the effect that (quoting
Jonathan del Strother) "... a line containing just 'FUNCNAME' (terminated by
a newline) will be matched by the pattern '^(FUNCNAME.$)' but not
'^(FUNCNAME$)'", and more simply not '^FUNCNAME$'.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since the newline is not removed from lines before pattern matching, a
pattern cannot match to the end of the line using the '$' operator without
using an additional operator which will indirectly match the '\n' character.
Introduce a test which should pass, but which does not due to this flaw.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test used the non-zero exit status of 'git diff' to indicate that a
negated funcname pattern, when placed last, was correctly rejected.
The problem with this is that 'git diff' always returns non-zero if it
finds differences in the files it is comparing, and the files must
contain differences in order to trigger the funcname pattern codepath.
Instead of checking for non-zero exit status, make sure the expected
error message is printed.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some confusing tutorials suggested that it would be a good idea to fetch
into the current branch with something like this:
git fetch origin master:master
(or even worse: the same command line with "pull" instead of "fetch").
While it might make sense to store what you want to pull, it typically is
plain wrong when the current branch is "master". This should only be
allowed when (an incorrect) "git pull origin master:master" tries to work
around by giving --update-head-ok to underlying "git fetch", and otherwise
we should refuse it, but somewhere along the lines we lost that behavior.
The check for the current branch is now _only_ performed in non-bare
repositories, which is an improvement from the original behaviour.
Some newer tests were depending on the broken behaviour of "git fetch"
this patch fixes, and have been adjusted.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 969c8775 introduced a test which uses the non-portable construct:
command1 && ! command2 | command3
which must be
command1 && ! (command2 | command3)
to work on bsd shells (this is another example of bbf08124, which fixed
several similar cases).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows multiple paths to be specified on stdin.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
According to the message of commit 0fe7c1de16,
"git diff" with three or more trees expects the merged tree first followed by
the parents, in order. However, this command reversed the order of its
arguments, resulting in confusing diffs. A comment /* Again, the revs are all
reverse */ suggested there was a reason for this, but I can't figure out the
reason, so I removed the reversal of the arguments. Test case included.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since dbf5e1e9, the '--no-validate' option is a Getopt::Long boolean
option. The '--no-' prefix (as in --no-validate) for boolean options
is not supported in Getopt::Long version 2.32 which was released with
Perl 5.8.0. This version only supports '--no' as in '--novalidate'.
More recent versions of Getopt::Long, such as version 2.34, support
either prefix. So use the older form in the tests.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We carefully verify that the input to git-apply is sane,
including cross-checking that the filenames we see in "+++"
headers match what was provided on the command line of "diff
--git". When --directory is used, however, we ended up
comparing the unadorned name to one with the prepended root,
causing us to complain about a mismatch.
We simply need to prepend the root directory, if any, when
pulling the name out of the git header.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
rebase -i: do not fail when there is no commit to cherry-pick
test-lib: fix color reset in say_color()
fix pread()'s short read in index-pack
Conflicts:
csum-file.c
In case there is no commit to apply (for example because you rebase to
upstream and all your local patches have been applied there), do not
fail. The non-interactive rebase already behaves that way.
Do this by introducing a new command, "noop", which is substituted for
an empty commit list, so that deleting the commit list can still abort
as before.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When executing a single test with colors enabled, the cursor was not set
back to the previous one, and you had to hit an extra enter to get it
back.
Work around this problem by calling 'tput sgr0' before printing the
final newline.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The new -v option forces the progressbar, even in case the output
is not a terminal. This can be useful if the caller is an IDE or
wrapper which wants to scrape the progressbar from stderr and show
its information in a different format.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Do not use errno when pread() returns 0
git init: --bare/--shared overrides system/global config
git-push.txt: Describe --repo option in more detail
git rm: refresh index before up-to-date check
Fix a few typos in relnotes
If core.bare or core.sharedRepository are set in /etc/gitconfig or
~/.gitconfig, then 'git init' will read the values when constructing a
new config file; reading them, however, will override the values
specified on the command line. In the case of --bare, this ends up
causing a segfault, without the repository being properly initialised;
in the case of --shared, the permissions are set according to the
existing config settings, not what was specified on the command line.
This fix saves any specified values for --bare and --shared prior to
reading existing config settings, and restores them after reading but
before writing the new config file. core.bare is ignored in all
situations, while core.sharedRepository will only be used if --shared
is not specified to git init.
Also includes testcases which use a specified global config file
override, demonstrating the former failure scenario.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since "git rm" is supposed to be porcelain, we should convince it to
be user friendly by refreshing the index itself.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It is sometimes desirable to disable the safety net of pre-rebase hook
when the user knows what he is doing (for example, when the original
changes on the branch have not been shown to the public yet).
This teaches --no-verify option to git-rebase, which is similar to the way
pre-commit hook is bypassed by git-commit.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
[ew: fixed a warning to stderr causing t9108 to fail]
Signed-off-by: Florian Ragwitz <rafl@debian.org>
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Update release notes for 1.6.0.3
Teach rebase -i to honor pre-rebase hook
docs: describe pre-rebase hook
do not segfault if make_cache_entry failed
make prefix_path() never return NULL
fix bogus "diff --git" header from "diff --no-index"
Fix fetch/clone --quiet when stdout is connected
builtin-blame: Fix blame -C -C with submodules.
bash: remove fetch, push, pull dashed form leftovers
Conflicts:
diff.c
The original git-rebase honored pre-rebase hook so that public branches
can be protected from getting rebased, but rebase --interactive ignored
the hook entirely. This fixes it.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When "git diff --no-index" is given an absolute pathname, it
would generate a diff header with the absolute path
prepended by the prefix, like:
diff --git a/dev/null b/foo
Not only is this nonsensical, and not only does it violate
the description of diffs given in git-diff(1), but it would
produce broken binary diffs. Unlike text diffs, the binary
diffs don't contain the filenames anywhere else, and so "git
apply" relies on this header to figure out the filename.
This patch just refuses to use an invalid name for anything
visible in the diff.
Now, this fixes the "git diff --no-index --binary a
/dev/null" kind of case (and we'll end up using "a" as the
basename), but some other insane cases are impossible to
handle. If you do
git diff --no-index --binary a /bin/echo
you'll still get a patch like
diff --git a/a b/bin/echo
old mode 100644
new mode 100755
index ...
and "git apply" will refuse to apply it for a couple of
reasons, and the diff is simply bogus.
And that, btw, is no longer a bug, I think. It's impossible
to know whethe the user meant for the patch to be a rename
or not. And as such, refusing to apply it because you don't
know what name you should use is probably _exactly_ the
right thing to do!
Original problem reported by Imre Deak. Test script and problem
description by Jeff King.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since commit 6bb6b034 (builtin-commit: use commit_tree(), 2008-09-10),
builtin-commit performs a reduce_heads() unconditionally. However,
it's not always needed, and in some cases even harmful.
reduce_heads() is not needed for the initial commit or for an
"ordinary" commit, because they don't have any or have only one
parent, respectively.
reduce_heads() must be avoided when 'git commit' is run after a 'git
merge --no-ff --no-commit', otherwise it will turn the
non-fast-forward merge into fast-forward. For the same reason,
reduce_heads() must be avoided when amending such a merge commit.
To resolve this issue, 'git merge' will write info about whether
fast-forward is allowed or not to $GIT_DIR/MERGE_MODE. Based on this
info, 'git commit' will only perform reduce_heads() when it's
committing a merge and fast-forward is enabled.
Also add test cases to ensure that non-fast-forward merges are
committed and amended properly.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In case a file is touched but has no real changes then we just have to
update the index and should not error out.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This testcase ensures that upstream changes to submodule properties
can be updated using the sync subcommand. This particular test
changes the submodule URL upstream and uses the sync command to update
an existing checkout.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
gitweb: Add path_info tests to t/t9500-gitweb-standalone-no-errors.sh
gitweb: Fix two 'uninitialized value' warnings in git_tree()
Solaris: Use OLD_ICONV to avoid compile warnings
gitweb: remove PATH_INFO from $my_url and $my_uri
Note that those tests only check that there are no errors nor
warnings from Perl; they do not check for example if gitweb doesn't
use ARRAY(0x8e3cc20) instead of correct value in links, etc.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As a result of implementation details, 'git rebase' could
previously only preserve merges in interactive mode. That
limitation was hard for users to understand and awkward to
explain.
This patch works around it by running the interactive rebase
helper git-rebase--interactive with GIT_EDITOR set to ':'
when the user passes "-p" but not "-i" to the rebase command.
The effect is that the interactive rebase helper is used but
the user never sees an editor.
The test-case included in this patch was originally written
by Stephen Habermann <stephen@exigencecorp.com>, but has
been extensively modified since its creation.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We try to avoid using the "-q" or "-e" options, as they are
largely useless, as explained in aadbe44f.
There is one exception for "-e" here, which is in t7701 used
to produce an "or" of patterns. This can be rewritten as an
egrep pattern.
This patch also removes use of "grep -F" in favor of the
more widely available "fgrep".
[sp: Tested on AIX 5.3 by Mike Ralphson,
Tested on MinGW by Johannes Sixt]
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Mike Ralphson <mike@abacus.co.uk>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* bc/master-diff-hunk-header-fix:
Clarify commit error message for unmerged files
Use strchrnul() instead of strchr() plus manual workaround
Use remove_path from dir.c instead of own implementation
Add remove_path: a function to remove as much as possible of a path
git-submodule: Fix "Unable to checkout" for the initial 'update'
Clarify how the user can satisfy stash's 'dirty state' check.
t4018-diff-funcname: test syntax of builtin xfuncname patterns
t4018-diff-funcname: test syntax of builtin xfuncname patterns
make "git remote" report multiple URLs
diff hunk pattern: fix misconverted "\{" tex macro introducers
diff: fix "multiple regexp" semantics to find hunk header comment
diff: use extended regexp to find hunk headers
diff: use extended regexp to find hunk headers
diff.*.xfuncname which uses "extended" regex's for hunk header selection
diff.c: associate a flag with each pattern and use it for compiling regex
diff.c: return pattern entry pointer rather than just the hunk header pattern
Conflicts:
builtin-merge-recursive.c
t/t7201-co.sh
xdiff-interface.h
* maint: (41 commits)
Clarify commit error message for unmerged files
Use strchrnul() instead of strchr() plus manual workaround
Use remove_path from dir.c instead of own implementation
Add remove_path: a function to remove as much as possible of a path
git-submodule: Fix "Unable to checkout" for the initial 'update'
Clarify how the user can satisfy stash's 'dirty state' check.
Remove empty directories in recursive merge
Documentation: clarify the details of overriding LESS via core.pager
Update release notes for 1.6.0.3
checkout: Do not show local changes when in quiet mode
for-each-ref: Fix --format=%(subject) for log message without newlines
git-stash.sh: don't default to refs/stash if invalid ref supplied
maint: check return of split_cmdline to avoid bad config strings
builtin-prune.c: prune temporary packs in <object_dir>/pack directory
Do not perform cross-directory renames when creating packs
Use dashless git commands in setgitperms.perl
git-remote: do not use user input in a printf format string
make "git remote" report multiple URLs
Start draft release notes for 1.6.0.3
git-repack uses --no-repack-object, not --no-repack-delta.
...
Conflicts:
RelNotes
* bc/maint-diff-hunk-header-fix:
t4018-diff-funcname: test syntax of builtin xfuncname patterns
diff hunk pattern: fix misconverted "\{" tex macro introducers
diff: use extended regexp to find hunk headers
diff.*.xfuncname which uses "extended" regex's for hunk header selection
diff.c: associate a flag with each pattern and use it for compiling regex
diff.c: return pattern entry pointer rather than just the hunk header pattern
Conflicts:
Documentation/gitattributes.txt
* jc/better-conflict-resolution:
Fix AsciiDoc errors in merge documentation
git-merge documentation: describe how conflict is presented
checkout --conflict=<style>: recreate merge in a non-default style
checkout -m: recreate merge when checking out of unmerged index
git-merge-recursive: learn to honor merge.conflictstyle
merge.conflictstyle: choose between "merge" and "diff3 -m" styles
rerere: understand "diff3 -m" style conflicts with the original
rerere.c: use symbolic constants to keep track of parsing states
xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or less
xmerge.c: minimum readability fixups
xdiff-merge: optionally show conflicts in "diff3 -m" style
xdl_fill_merge_buffer(): separate out a too deeply nested function
checkout --ours/--theirs: allow checking out one side of a conflicting merge
checkout -f: allow ignoring unmerged paths when checking out of the index
Conflicts:
Documentation/git-checkout.txt
builtin-checkout.c
builtin-merge-recursive.c
t/t7201-co.sh
* maint:
Remove empty directories in recursive merge
Documentation: clarify the details of overriding LESS via core.pager
Conflicts:
builtin-merge-recursive.c
The code was actually supposed to do that, but was accidentally broken.
Noticed by Anders Melchiorsen.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* mv/merge-recursive:
builtin-merge: release the lockfile in try_merge_strategy()
merge-recursive: get rid of virtual_id
merge-recursive: move current_{file,directory}_set to struct merge_options
merge-recursive: move the global obuf to struct merge_options
merge-recursive: get rid of the index_only global variable
merge-recursive: move call_depth to struct merge_options
cherry-pick/revert: make direct internal call to merge_tree()
builtin-merge: avoid run_command_v_opt() for recursive and subtree
merge-recursive: introduce merge_options
merge-recursive.c: Add more generic merge_recursive_generic()
Split out merge_recursive() to merge-recursive.c
* mv/commit-tree:
t7603: add new testcases to ensure builtin-commit uses reduce_heads()
builtin-commit: use commit_tree()
commit_tree(): add a new author parameter
* maint:
Update release notes for 1.6.0.3
checkout: Do not show local changes when in quiet mode
for-each-ref: Fix --format=%(subject) for log message without newlines
git-stash.sh: don't default to refs/stash if invalid ref supplied
maint: check return of split_cmdline to avoid bad config strings
As the testcase demonstrates, it's possible for split_cmdline to return -1 and
deallocate any memory it's allocated, if the config string is missing an end
quote. In both the cases below, which are the only calling sites, the return
isn't checked, and using the pointer causes a pretty immediate segfault.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
[jc: fixes bibtex pattern breakage exposed by this test]
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suppose you're using git-svn to work with a certain SVN repository.
Since you don't like 'git-svn fetch' to take forever, and you don't want
to accidentally interrupt it and end up corrupting your repository, you
set up a remote Git repository to mirror the SVN repository, which does
its own 'git-svn fetch' on a cronjob; now you can 'git-fetch' from the
Git mirror into your local repository, and still dcommit to SVN when you
have changes to push.
After you do this, though, git-svn will get very confused if you ever
try to do 'git-svn fetch' in your local repository again, since its
rev_map will differ from the branch's head, and it will be unable to
fetch new commits from SVN because of the metadata conflict. But all
the necessary metadata are there in the Git commit message; git-svn
already knows how to rebuild rev_map files that get blown away, by
using the metadata.
This patch teaches git-svn do a partial rebuild of the rev_map to
match the true state of the branch, if it ever is used to fetch again.
This will only work for projects not using either noMetadata or
useSvmProps configuration options; if you are using these options,
git-svn will fall back to the previous behaviour.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
[jc: use expect_failure to mark the test to expose existing breakage]
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git fetch" auto-follows tags, it should not download excess ones.
This new test makes sure that condition.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you fail to update refs to change branches in checkout, your index
and working tree are left already updated. We don't have an easy way
to undo this, but at least we can check things that would make the
creation of a new branch fail. These checks were in the shell version,
and were lost in the C conversion.
The messages are from the shell version, and should probably be made nicer.
[jc: added test to t7201]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* bc/maint-diff-hunk-header-fix:
diff.*.xfuncname which uses "extended" regex's for hunk header selection
diff.c: associate a flag with each pattern and use it for compiling regex
diff.c: return pattern entry pointer rather than just the hunk header pattern
Cosmetical command name fix
Start conforming code to "git subcmd" style part 3
t9700/test.pl: remove File::Temp requirement
t9700/test.pl: avoid bareword 'STDERR' in 3-argument open()
GIT 1.6.0.2
Fix some manual typos.
Use compatibility regex library also on FreeBSD
Use compatibility regex library also on AIX
Update draft release notes for 1.6.0.2
Use compatibility regex library for OSX/Darwin
git-svn: Fixes my() parameter list syntax error in pre-5.8 Perl
Git.pm: Use File::Temp->tempfile instead of ->new
t7501: always use test_cmp instead of diff
Start conforming code to "git subcmd" style part 2
diff: Help "less" hide ^M from the output
checkout: do not check out unmerged higher stages randomly
Conflicts:
Documentation/git.txt
Documentation/gitattributes.txt
Makefile
diff.c
t/t7201-co.sh
* maint:
sha1_file: link() returns -1 on failure, not errno
Make git archive respect core.autocrlf when creating zip format archives
Add new test to demonstrate git archive core.autocrlf inconsistency
gitweb: avoid warnings for commits without body
Clarified gitattributes documentation regarding custom hunk header.
git-svn: fix handling of even funkier branch names
git-svn: Always create a new RA when calling do_switch for svn://
git-svn: factor out svnserve test code for later use
diff/diff-files: do not use --cc too aggressively
* cc/bisect:
bisect: remove "checkout_done" variable used when checking merge bases
bisect: only check merge bases when needed
bisect: test merge base if good rev is not an ancestor of bad rev
Currently, the hunk headers produced by 'diff -p' are customizable by
setting the diff.*.funcname option in the config file. The 'funcname' option
takes a basic regular expression. This functionality was designed using the
GNU regex library which, by default, allows using backslashed versions of
some extended regular expression operators, even in Basic Regular Expression
mode. For example, the following characters, when backslashed, are
interpreted according to the extended regular expression rules: ?, +, and |.
As such, the builtin funcname patterns were created using some extended
regular expression operators.
Other platforms which adhere more strictly to the POSIX spec do not
interpret the backslashed extended RE operators in Basic Regular Expression
mode. This causes the pattern matching for the builtin funcname patterns to
fail on those platforms.
Introduce a new option 'xfuncname' which uses extended regular expressions,
and advertise it _instead_ of funcname. Since most users are on GNU
platforms, the majority of funcname patterns are created and tested there.
Advertising only xfuncname should help to avoid the creation of non-portable
patterns which work with GNU regex but not elsewhere.
Additionally, the extended regular expressions may be less ugly and
complicated compared to the basic RE since many common special operators do
not need to be backslashed.
For example, the GNU Basic RE:
^[ ]*\\(\\(public\\|static\\).*\\)$
becomes the following Extended RE:
^[ ]*((public|static).*)$
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is currently no call to git_config at the start of cmd_archive.
When creating tar archives the core config is read as a side-effect of
reading the tar specific config, but this doesn't happen for zip
archives.
The consequence is that in a configuration with core.autocrlf set,
although files in a tar archive are created with crlf line endings,
files in a zip archive retain unix line endings.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Acked-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apparently do_switch() tolerates the lack of escaping in less
funky branch names. For the really strange and scary ones, we
need to escape them properly. It strangely maintains compatible
with the existing handling of branch names with spaces and
exclamation marks.
Reported-by: m.skoric@web.de ($gmane/94677)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Not doing so caused the "Malformed network data" error when a directoy
was deleted and replaced with a copy from an older version.
Signed-off-by: Alec Berryman <alec@thened.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The object oriented version of File::Temp is a rather new incarnation it
seems. The File::Temp man page for v5.8.0 says "(NOT YET IMPLEMENTED)" in
the 'Objects' section. Instead of creating a file with a unique name in
the system TMPDIR, we can create our own temporary file with a static
name and use that instead.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk> on RHEL 3, Perl 5.8.0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some versions of perl complain when 'STDERR' is used as the third argument
in the 3-argument form of open(). Convert to the 2-argument form which is
described for duping STDERR in my second edition camel book.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk> on RHEL 3, Perl 5.8.0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes for 1.6.0.2
Use compatibility regex library for OSX/Darwin
git-svn: Fixes my() parameter list syntax error in pre-5.8 Perl
Git.pm: Use File::Temp->tempfile instead of ->new
t7501: always use test_cmp instead of diff
Conflicts:
Makefile
The standard libc regex library on OSX does not support alternation
in POSIX Basic Regular Expression mode. This breaks the diff.funcname
functionality on OSX.
To fix this, we use the GNU regex library which is already present in
the compat/ diretory for the MinGW port. However, simply adding compat/
to the COMPAT_CFLAGS variable causes a conflict between the system
fnmatch.h and the one present in compat/. To remedy this, move the
regex and fnmatch functionality to their own subdirectories in compat/
so they can be included seperately.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Tested-by: Mike Ralphson <mike@abacus.co.uk> (AIX)
Tested-by: Johannes Sixt <johannes.sixt@telecom.at> (MinGW)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This should make the output more readable (by default using diff -u)
when some tests fail.
Also changed the diff order from "current expected" to "expected
current".
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This changes "git-foo" to "git foo" when message strings in tests
name git subcommands.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also use "git hash-object" and "git rev-parse" without dash.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
OS X sed doesn't understand '\n' on the right side of a substitution.
Use a valid substitution character instead and use 'tr' to convert
those to a newline.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This replaces 'git-svn' with 'git svn' in the tests.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Subversion tests use too many "git-foo" form, so I am converting them
in two steps.
This first step replaces literal strings "remotes/git-svn" and "git-svn-id"
by introducing $remotes_git_svn and $git_svn_id constants defined as shell
variables. This will reduce the number of false hits from "git grep".
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apparently do_switch() tolerates the lack of escaping in less
funky branch names. For the really strange and scary ones, we
need to escape them properly. It strangely maintains compatible
with the existing handling of branch names with spaces and
exclamation marks.
Reported-by: m.skoric@web.de ($gmane/94677)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Once we committed the locked index, we should release the lockfile. In
most cases this is done automatically when the process ends, but this is
not true in this case.
[jc: with additional tests from Eric Raible]
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
git-svn: set auto_props when renaming files
t9124: clean up chdir usage
git-svn: fix 'info' tests for unknown items
git-svn: match SVN 1.5 behaviour of info' on unknown item
git svn info: always quote URLs in 'info' output
git svn info: make info relative to the current directory
git svn info: tests: fix ptouch argument order in setup
git svn info: tests: use test_cmp instead of git-diff
git svn info: tests: do not use set -e
git svn info: tests: let 'init' test run with SVN 1.5
git svn: catch lack of upstream info for dcommit earlier
git-svn: check error code of send_txstream
git-svn: Send deltas during commits
git-svn: Introduce SVN::Git::Editor::_chg_file_get_blob
git-svn: extract base blob in generate_diff
Patch-by: Paul Talacko <gnuruandstuff@yahoo.co.uk>:
<http://article.gmane.org/gmane.comp.version-control.git/95006>
> Hello,
>
> There's an issue in git-svn as autoprops are not applied to
> renamed files, only to added files.
>
> This patch fixes the bug.
[ew: added test case]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Spawn subshells when running things in subdirectories instead of
chdir-ing to the path of an undefined variable, which is
confusing.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* maint:
Update draft release notes for 1.6.0.2
stash: refresh the index before deciding if the work tree is dirty
Mention the fact that 'git annotate' is only for backward compatibility.
"blame -c" should be compatible with "annotate"
git-gui: Fix diff parsing for lines starting with "--" or "++"
git-gui: Fix string escaping in po2msg.sh
git gui: show diffs with a minimum of 1 context line
git-gui: update all remaining translations to French.
git-gui: Update french translation
Tries to shorten the refname to a non-ambiguous name.
Szeder Gábor noticed that the git bash completion takes a
tremendous amount of time to strip leading components from
heads and tags refs (i.e. refs/heads, refs/tags, ...). He
proposed a new atom called 'refbasename' which removes at
most two leading components from the ref name.
I myself, proposed a more dynamic solution, which strips off
common leading components with the matched pattern.
But the current bash solution and both proposals suffer from
one mayor problem: ambiguous refs.
A ref is ambiguous, if it resolves to more than one full refs.
I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The
(short) ref xyzzy can point to both refs.
( Note: Its irrelevant whether the referenced objects are the
same or not. )
This proposal solves this by checking for ambiguity of the
shorten ref name.
The shortening is done with the same rules for resolving refs
but in the reverse order. The short name is checked if it
resolves to a different ref.
To continue the above example, the output would be like this:
heads/xyzzy
xyzzy
So, if you want just tags, xyzzy is not ambiguous, because it
will resolve to a tag. If you need the heads you get a also
a non-ambiguous short form of the ref.
To integrate this new format into the bash completion to get
only non-ambiguous refs is beyond the scope of this patch.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous tests all expected the results from SVN and Git to be
identical, and expected both to return success. This cannot be
guaranteed: SVN changed the message style between 1.4 and 1.5, and
in 1.5, sets a failure exit code.
Change the tests to verify that 'git svn info <item>' sets a failure
exit code, and that its output contains the file name. This should
hopefully catch all other errors.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Changes 'git svn info' to always URL-escape the 'URL' and 'Repository'
fields and --url output, like SVN (at least 1.5) does.
Note that reusing the escape_url() further down in Git::SVN::Ra is not
possible because it only triggers for http(s) URLs. I did not know
whether extending it to all schemes would break SVN access anywhere,
so I made a new one that quotes in all schemes.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Previously 'git svn info <path>' would always treat the <path> as
relative to the working directory root, with a default of ".". This
does not match the behaviour of 'svn info'. Prepend $(git rev-parse
--show-prefix) to the path used inside cmd_info to make it relative to
the current working directory.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
The arguments must be <gitwc-path> <svnwc-path>, otherwise it fails to
update the timestamps (without setting a failure exit code) and
results in bad test output later on.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-diff does not appear to return the correct exit values, and gives
a false success for more than half (!) of the tests due to the space
in "trash directory" which git-svn fails to encode.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Exiting in the middle of a test confuses the test suite, which will
just say "FATAL: Unexpected exit with code 1" in response to a failed
test, instead of actually diagnosing failure and continuing with the
next test.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
