Unpacked objects should receive the timestamp of the pack they were
unpacked from. Check.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the user specifies a ref by a reflog entry older than
one we have (e.g., "HEAD@{20 years ago"}), we issue a
warning and give them the "from" value of the oldest reflog
entry. That is, we say "we don't know what happened before
this entry, but before this we know we had some particular
SHA1".
However, the oldest reflog entry is often a creation event
such as clone or branch creation. In this case, the entry
claims that the ref went from "00000..." (the null sha1) to
the new value, and the reflog lookup returns the null sha1.
While this is technically correct (the entry tells us that
the ref didn't exist at the specified time) it is not
terribly useful to the end user. What they probably want
instead is "the oldest useful sha1 that this ref ever had".
This patch changes the behavior such that if the oldest ref
would return the null sha1, it instead returns the first
value the ref ever had.
We never discovered this problem in the test scripts because
we created "fake" reflogs that had only a specified segment
of history. This patch updates the tests with a creation
event at the beginning of history.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a patch modifies the last line of a file that previously had no
terminating '\n', it looks like
-old text
\ No newline at end of file
+new text
Hence, a '\' line does not signal the end of the hunk. This modifies
'git apply --recount' to take this into account.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we match a lightweight (non-annotated tag) as the name to
output and --long was requested we do not have a tag, nor do
we have a tagged object to display. Instead we must use the
object we were passed as input for the long format display.
Reported-by: Mark Burton <markb@ordern.com>
Backtraced-by: Mikael Magnusson <mikachu@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We don't need test results to be committed if we're fixing a test.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes, the easiest way to fix up a patch is to edit it directly, even
adding or deleting lines. Now, many people are not as divine as certain
benevolent dictators as to update the hunk headers correctly at the first
try.
So teach the tool to do it for us.
[jc: with tests]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When working with a lot of people who backport patches all day long, every
once in a while I get a patch that modifies the same file more than once
inside the same patch. git-apply either fails if the second change relies
on the first change or silently drops the first change if the second change
is independent.
The silent part is the scary scenario for us. Also this behaviour is
different from the patch-utils.
I have modified git-apply to create a table of the filenames of files it
modifies such that if a later patch chunk modifies a file in the table it
will buffer the previously changed file instead of reading the original file
from disk.
Logic has been put in to handle creations/deletions/renames/copies. All the
relevant tests of git-apply succeed.
A new test has been added to cover the cases I addressed.
The fix is relatively straight-forward.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches "diff --check" to detect and complain if the change
adds lines that look like leftover conflict markers.
We should be able to remove the old Perl script used in the sample
pre-commit hook and modernize the script with this facility.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a patch adds new blank lines at the end, "git apply --whitespace"
warns. This teaches "diff --check" to do the same.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff --check" should return non-zero when there was any whitespace
error but the code only paid attention to the error status of the last
new line in the patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, we did a sanity check by doing for-each-ref
using each possible format atom. However, we never checked
the actual output produced by that atom, which recently let
an obvious bug go undetected for some time.
While we're at it, also clean up a few '!' into
test_must_fail.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The perldiag(1) has following to say about this:
"Can't do inplace edit without backup"
(F) You're on a system such as MS-DOS that gets confused if
you try reading from a deleted (but still opened) file. You
have to say -i.bak, or some such.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The shell version used to use "mkdir -p" to create the repo
path, but the C version just calls "mkdir". Let's replicate
the old behavior. We have to create the git and worktree
leading dirs separately; while most of the time, the
worktree dir contains the git dir (as .git), the user can
override this using GIT_WORK_TREE.
We can reuse safe_create_leading_directories, but we need to
make a copy of our const buffer to do so. Since
merge-recursive uses the same pattern, we can factor this
out into a global function. This has two other cleanup
advantages for merge-recursive:
1. mkdir_p wasn't a very good name. "mkdir -p foo/bar" actually
creates bar, but this function just creates the leading
directories.
2. mkdir_p took a mode argument, but it was completely
ignored.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The shell version used to use "mkdir -p" to create the repo
path, but the C version just calls "mkdir". Let's replicate
the old behavior. We have to create the git and worktree
leading dirs separately; while most of the time, the
worktree dir contains the git dir (as .git), the user can
override this using GIT_WORK_TREE.
We can reuse safe_create_leading_directories, but we need to
make a copy of our const buffer to do so. Since
merge-recursive uses the same pattern, we can factor this
out into a global function. This has two other cleanup
advantages for merge-recursive:
1. mkdir_p wasn't a very good name. "mkdir -p foo/bar" actually
creates bar, but this function just creates the leading
directories.
2. mkdir_p took a mode argument, but it was completely
ignored.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suppose someone fetches git-svn-ified commits from another repo and then
attempts to use 'git-svn init --rewrite-root=foo bar'. Using git svn rebase
after that will fail badly:
* For each commit tried by working_head_info, rebuild is called indirectly.
* rebuild will iterate over all commits and skip all of them because the
URL does not match. Because of that no rev_map file is generated at all.
* Thus, rebuild will run once for every commit. This takes ages.
* In the end there still isn't any rev_map file and thus working_head_info
fails.
Addressing this behaviour fixes an apparently not too uncommon problem with
providing git-svn mirrors of Subversion repositories. Some repositories are
accessed using different URLs depending on whether the user has push
privileges or not. In the latter case, an anonymous URL is often used that
differs from the push URL. Providing a mirror that is usable in both cases
becomes a lot more possible with this change.
Signed-off-by: Jan Krüger <jk@jk.gs>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch serves two purposes:
1. test-parse-option.c should be a more complete
example for the parse-options API, and
2. there have been no tests for OPT_CALLBACK,
OPT_DATE, OPT_BIT, OPT_SET_INT and OPT_SET_PTR
before.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an argument for an option is optional, short options don't need a
space between the option and the argument, and long options need a "=".
Otherwise, arguments are misinterpreted.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
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.
Add description of GIT_SKIP_TESTS variable, taken almost verbatim
(adjusting for conventions in t/README) from the commit message in
04ece59 (GIT_SKIP_TESTS: allow users to omit tests that are known to break)
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the arguments to test_must_fail() begin with a variable assignment,
test_must_fail() attempts to execute the variable assignment as a command.
This fails, and so test_must_fail returns with a successful status value
without running the command it was intended to test.
For example, the following script:
#!/bin/sh
test_must_fail () {
"$@"
test $? -gt 0 -a $? -le 129
}
foo='wo adrian'
test_must_fail foo='yo adrian' sh -c 'echo foo: $foo'
always exits zero and prints the message:
test.sh: line 3: foo=yo adrian: command not found
Test 16 calls test_must_fail in such a way and therefore has not been
testing whether git 'do[es] not fire editor in the presence of conflicts'.
A workaround is to set and export the variable in a normal way, not
using one-shot notation. Because this would affect the remainder of
the process, the test is done inside a subshell.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5515-fetch-merge-logic removes many, but not all, refs between each test.
This is done by removing the corresponding refs/foo/* files in the .git/refs
hierarchy. However, once "git clone" starts producing packed refs, these refs
will no longer be in the .git/refs hierarchy, but rather listed in
.git/packed-refs. This patch teaches t5515-fetch-merge-logic to remove the
refs using "git update-ref -d" which properly handles packed refs.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds the --import-marks and --export-marks to fast-export. These import
and export the marks used to for all revisions exported in a similar fashion
to what fast-import does. The format is the same as fast-import, so you can
create a bidirectional importer / exporter by using the same marks file on
both sides.
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a shell script (t/t9700-perl-git.sh) that sets up a git repository
and a perl script (t/t9700/test.pl) that runs the actual tests.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is for running external test scripts in other programming
languages that provide continuous output about their tests. Using
test_expect_success (like "test_expect_success 'description' 'perl
test-script.pl'") doesn't suffice here because test_expect_success
eats stdout in non-verbose mode, which is not fixable without major
file descriptor trickery.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a --long-tests option to test-lib.sh, which enables tests to
selectively run more exhaustive (longer running, potentially
brute-force) tests. Such exhaustive tests would only be useful if one
works on the specific module that is being tested -- for a general "cd
t/; make" to check whether everything is OK, such exhaustive tests
shouldn't be run by default since the longer it takes to run the
tests, the less often they are actually run.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
match_explicit is called for each push refspec to try to
fully resolve the source and destination sides of the
refspec. Currently, we look at each refspec and report
errors on both the source and the dest side before aborting.
It makes sense to report errors for each refspec, since an
error in one is independent of an error in the other.
However, reporting errors on the 'dst' side of a refspec if
there has been an error on the 'src' side does not
necessarily make sense, since the interpretation of the
'dst' side depends on the 'src' side (for example, when
creating a new unqualified remote ref, we use the same type
as the src ref).
This patch lets match_explicit return early when the src
side of the refspec is bogus. We still look at all of the
refspecs before aborting the push, though.
At the same time, we clean up the call signature, which
previously took an extra "errs" flag. This was pointless, as
we didn't act on that flag, but rather just passed it back
to the caller. Instead, we now use the more traditional
"return -1" to signal an error, and the caller aggregates
the error count.
This change fixes two bugs, as well:
- the early return avoids a segfault when passing a NULL
matched_src to guess_ref()
- the check for multiple sources pointing to a single dest
aborted if the "err" flag was set. Presumably the intent
was not to bother with the check if we had no
matched_src. However, since the err flag was passed in
from the caller, we might abort the check just because a
previous refspec had a problem, which doesn't make
sense.
In practice, this didn't matter, since due to the error
flag we end up aborting the push anyway.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Improve the git-svn-author test to check that extra newlines aren't inserted
into commit messages as they take a round trip from git to svn and back.
We test both with and without the --add-author-from option to git-svn.
git-svn: test that svn repo doesn't have extra newlines.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that all of the policy violations have been cleaned up,
we can turn this on and start checking incoming patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some cases, we produce a diffstat line even though no
lines have changed (e.g., because of an exact rename). In
this case, there is no +/- "graph" after the number of
changed lines. However, we output the space separator
unconditionally, meaning that these lines contained a
trailing space character.
This isn't a huge problem, but in cleaning up the output we
are able to eliminate some trailing whitespace from a test
vector.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When outputting a usage message with a blank line in the
header, we would output a line with four spaces. Make this
truly a blank line.
This helps us remove trailing whitespace from a test vector.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All of these violations are necessary parts of the tests
(which are generally checking the behavior of trailing
whitespace, or contain diff fragments with empty lines).
Our solution is two-fold:
1. Process input with whitespace problems using tr. This
has the added bonus that it becomes very obvious where
the bogus whitespace is intended to go.
2. Move large diff fragments into their own supplemental
files. This gets rid of the whitespace problem, since
supplemental files are not checked, and it also makes
the test script a bit easier to read.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These violations are simply wrong, but were never caught
because whitespace policy checking is turned off in the test
scripts.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test did "reset --hard" (where the HEAD commit has an empty
blob at path "empty") followed by "> empty", expecting that
the index does not notice the file _changed_ since git wrote
it out upon "reset" if the redirection is done quickly enough.
There was no need to do the emptying, and it gave a wrong result
if "reset --hard" happened on time T and then ">empty" happened on
the next second T+1. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only ignore whitespace errors in t/tNNNN-*.sh and the t/tNNNN
subdirectories. Other files (like test libraries) should still be
checked.
Also fix a whitespace error in t/test-lib.sh.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This command is really too quiet which make it unconfortable to use.
Also implement a --dry-run option, in place of the original -n one, to
list stale tracking branches that will be pruned, but do not actually
prune them.
Add a test case for --dry-run.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The perl version accepted a -n flag, to show local informations only
without querying remote heads, that seems to have been lost in the C
revrite.
This restores the older behaviour and add a test case.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brandon Casey