Since c869753e, core.filemode is hardwired to false on Cygwin.
So this test had no chance to succeed, since an early commit
(changing just the filemode) failed, and therefore all subsequent
tests.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Suggested by Jakub Narebski <jnareb@gmail.com> on the list.
When we send a value to store_write_pair(), make sure that the value
that gets read out matches the one passed in. This means that for any
value that contains leading or trailing whitespace or any comment
character (# and ;), we need to surround it in quotes.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching branches with "git checkout", we internally did $arg^0
(aka $arg^{commit}) suffix but there was no need to.
The improvement is easily visible in the change to an existing
test t/3200-branch.sh in this commit; it was expecting rather
ugly message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The logic in an earlier round to detect reflog entries that
point at a broken commit was not sufficient. Just like we do
not trust presense of a commit during pack transfer (we trust
only our refs), we should not trust a commit's presense, even if
the tree of that commit is complete.
A repository that had reflog enabled on some of the refs that
was rewound and then run git-repack or git-prune from older
versions of git can have reflog entries that point at a commit
that still exist but lack commits (or trees and blobs needed for
that commit) between it and some commit that is reachable from
one of the refs.
This revamps the logic -- the definition of "broken commit"
becomes: a commit that is not reachable from any of the refs and
there is a missing object among the commit, tree, or blob
objects reachable from it that is not reachable from any of the
refs. Entries in the reflog that refer to such a commit are
expired.
Since this computation involves traversing all the reachable
objects, i.e. it has the same cost as 'git prune', it is enabled
only when a new option --fix-stale. Fortunately, once this is
run, we should not have to ever worry about missing objects,
because the current prune and pack-objects know about reflogs
and protect objects referred by them.
Unfortunately, this will be absolutely necessary to help people
migrate to the newer prune and repack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier test timestamp was too old; I forgot that the bare
unixtime integer had to be after Jan 1, 2000. This changes
test_tick to use the git-epoch timestamp.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This removes some unnecessary 'svn up' calls throughout
t9103-git-svn-graft-branches.sh:
* removed an 'svn log' call that was leftover from debugging
* removed multiple git-svn calls with a multi-init / multi-fetch
combination (which weren't tested before, either)
* replaced `rev-list ... | head -n1` with `rev-parse ...`
(not sure what I was thinking when I wrote that)
All this saves about 9 seconds from a test run
(53s -> 44s for 'make t91*') on my 1.3GHz Athlon
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We don't support the svn command-line client anymore; nor
do we support anything before SVN 1.1.0, so we can be certain
symlinks will be supported in the SVN repository.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We require the libraries now, so we can create repositories
using them (and save some executable load time while we're at
it).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Verify that the update hooks work as documented/advertised. This is
a simple set of tests to check that the update hooks run with the
parameters expected, have their STDOUT and STDERR redirected to
the client side of the connection, and that their STDIN does not
contain any data (as its actually /dev/null).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes its necessary to supply a value as a power of two in a
configuration parameter. In this case the user may want to use the
standard suffixes such as K, M, or G to indicate that the numerical
value should be multiplied by a constant base before being used.
Shell scripts/etc. can also benefit from this automatic option
parsing with `git repo-config --int`.
[jc: with a couple of test and a slight input tightening]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a basic set of tests for the sliding window mmap. We mostly
focus on the verify-pack and pack-objects implementations (including
delta reuse) as these commands appear to cover the bulk of the
affected portions of sha1_file.c.
The test cases don't verify the virtual memory size used, as
this can differ from system to system. Instead it just verifies
that we can run with very low values for core.packedGitLimit and
core.packedGitWindowSize.
Adding pack_report() to the end of both builtin-verify-pack.c and
builtin-pack-objects.c and manually inspecting the statistics output
can help to verify that the total virtual memory size attributed
to pack mmap usage is what one might expect on the current system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When '*.ig' is ignored, and you have two files f.ig and d.ig/foo
in the working tree,
$ git add .
correctly ignored f.ig but failed to ignore d.ig/foo. This was
caused by a thinko in an earlier commit 4888c534, when we tried
to allow adding otherwise ignored files.
After reverting that commit, this takes a much simpler approach.
When we have an unmatched pathspec that talks about an existing
pathname, we know it is an ignored path the user tried to add,
so we include it in the set of paths directory walker returned.
This does not let you say "git add -f D" on an ignored directory
D and add everything under D. People can submit a patch to
further allow it if they want to, but I think it is a saner
behaviour to require explicit paths to be spelled out in such a
case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not that this reveals anything new, but I did test_tick shell
function in test-lib and found it rather cute and nice.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In some environments, certain tests have no way of succeeding
due to platform limitation, such as lack of 'unzip' program, or
filesystem that do not allow arbitrary sequence of non-NUL bytes
as pathnames.
You should be able to say something like
$ cd t
$ GIT_SKIP_TESTS=t9200.8 t9200-git-cvsexport-commit.sh
and even:
$ GIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' make test
to omit such tests. The value of the environment variable is a
SP separated list of patterns that tells which tests to skip,
and either can match the "t[0-9]{4}" part to skip the whole
test, or t[0-9]{4} followed by ".$number" to say which
particular test to skip.
Note that some tests in the existing test suite rely on previous
test item, so you cannot arbitrarily disable one and expect the
remainder of test to check what the test originally was intended
to check.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The function xdl_refine_conflicts() tries to break down huge
conflicts by doing a diff on the conflicting regions. However,
this does not make sense when one side is empty.
Worse, when one side is not only empty, but after EOF, the code
accessed unmapped memory.
Noticed by Luben Tuikov, Shawn Pearce and Alexandre Julliard, the
latter providing a test case.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have less code to worry about now. As a bonus, --revision
can be used to reliably skip parts of history whenever fetch is
run, not just the first time. I'm not sure why anybody would
want to skip history in the middle, however...
For people (nearly everyone at the moment) without the
do_switch() function in their Perl SVN library, the entire tree
must be refetched if --follow-parent is used and a parent is
found. Future versions of SVN will have a working do_switch()
function accessible via Perl.
Accessing repositories on the local machine (especially file://
ones) is also slightly slower as a result; but I suspect most
git-svn users will be using it to access remote repositories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I don't think anybody running tests needs to know they're
running init-db and creating a repository for testing.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We get an extra measure of error checking here as well.
While we're at it, also removed a less portable use of export.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It appears ISO-2022-JP is more widely accepted than ISO2022JP, so
rename it that way. We probably would need to have a way to skip
this test altogether in locale-challenged environments.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is plausible for somebody to want to view the commit log in a
different encoding from i18n.commitencoding -- the project's
policy may be UTF-8 and the user may be using a commit message
hook to run iconv to conform to that policy (and either not have
i18n.commitencoding to default to UTF-8 or have it explicitly
set to UTF-8). Even then, Latin-1 may be more convenient for
the usual pager and the terminal the user uses.
The new variable i18n.logoutputencoding is used in preference to
i18n.commitencoding to decide what encoding to recode the log
output in when git-log and friends formats the commit log message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The latest changes to git-commit have made it more verbose; and
I was running the setup of the tests outside of the test_expect_*,
so errors in those were not caught. Now we move them to where
they can be eval'ed and have their output trapped.
export var=value has been removed
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Displaying the SHA1 of 'their' branch (the branch being merged into
the current branch) is not nearly as friendly as just displaying
the name of that branch, especially if that branch is already local
to this repository.
git-merge now sets the environment variable 'GITHEAD_%(sha1)=%(name)'
for each argument it gets passed, making the actual input name that
resolved to the commit '%(sha1)' easily available to the invoked
merge strategy.
git-merge-recursive makes use of these environment variables when
they are available by using '%(name)' whenever it outputs the commit
identification rather than '%(sha1)'. This is most obvious in the
conflict hunks created by xdl_merge:
$ git mege sideb~1
<<<<<<< HEAD:INSTALL
Good!
=======
Oops.
>>>>>>> sideb~1:INSTALL
[jc: adjusted a test script and a minor constness glitch.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds --skip=<n> option to revision traversal machinery.
Documentation and test were added by Robert Fitzsimons.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we do not use --no-separate-remote anymore, there is no
reason to create that directory from the template.
t5510 test is updated to test both $GIT_DIR/remotes/ based
configuration and $GIT_DIR/config variable (credits to
Johannes).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of passing --template explicitely to init-db and clone, you can
just set the environment variable GIT_TEMPLATE_DIR.
Also make use of it in the tests, to make sure that the templates are
copied.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts commit 74d20040ca.
Version from Johannes to introduce GIT_TEMPLATE_DIR is simpler,
although I unconsciously stayed away from introducing yet another
environment variable.
The initial t/trash repository for testing was created properly
but over time we gained many tests that create secondary test
repositories with init-db or clone and they were not careful
enough.
This fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'update-index --replace --add A/B'
did not properly remove the file to make room for the new
directory.
There was a trivial logic error, most likely a cut & paste one,
dating back to quite early days of git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When renaming a branch, the corresponding config section should
be renamed, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Given a config like this:
# A config
[very.interesting.section]
not
The command
$ git repo-config --rename-section very.interesting.section bla.1
will lead to this config:
# A config
[bla "1"]
not
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
'set-tree' probably accurately describes what the command
formerly known as 'commit' does.
I'm not entirely sure that 'dcommit' should be renamed to 'commit'
just yet... Perhaps 'push' or 'push-changes'?
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using the command-line client was great for prototyping and
getting something working quickly. Eventually I found time
to study the library documentation and add support for using
the libraries which are much faster and more flexible when
it comes to supporting new features.
Note that we require version 1.1 of the SVN libraries, whereas
we supported the command-line svn client down to version 1.0.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
For multivars, the "git-repo-config name value ^$" is useful but
nonintuitive and troublesome to do repeatedly (since the value is not
at the end of the command line). This commit simply adds an --add
option that adds a new value to a multivar. Particularly useful for
tracking a new branch on a remote:
git-repo-config --add remote.origin.fetch +next:origin/next
Includes documentation and test.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
New and experienced Git users alike are finding out too late that
they forgot to enable reflogs in the current repository, and cannot
use the information stored within it to recover from an incorrectly
entered command such as `git reset --hard HEAD^^^` when they really
meant HEAD^^ (aka HEAD~2).
So enable reflogs by default in all future versions of Git, unless
the user specifically disables it with:
[core]
logAllRefUpdates = false
in their .git/config or ~/.gitconfig.
We only enable reflogs in repositories that have a working directory
associated with them, as shared/bare repositories do not have
an easy means to prune away old log entries, or may fail logging
entirely if the user's gecos information is not valid during a push.
This heuristic was suggested on the mailing list by Junio.
Documentation was also updated to indicate the new default behavior.
We probably should start to teach usuing the reflog to recover
from mistakes in some of the tutorial material, as new users are
likely to make a few along the way and will feel better knowing
they can recover from them quickly and easily, without fsck-objects'
lost+found features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is nicer to let the user know when a commit succeeded all the time,
not only the first time. Also the commit sha1 is much more useful than
the tree sha1 in this case.
This patch also introduces a -q switch to supress this message as well
as the summary of created/deleted files.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Prior to 65ac6e9c3f we deleted a file
from the working directory during a merge if the file existed before
the merge started but was renamed by the branch being merged in.
This broke in 65ac6e as git-merge-recursive did not actually update
the working directory on an uncontested rename.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Unify the handling for cases C (add/add) and D (modify/modify).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that we have git-merge-file, an RCS merge lookalike, we no longer
need it. So long, merge, and thanks for all the fish!
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This test case is based on the bug report by Shawn Pearce.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch uses git-apply to do the patching which simplifies the code a lot
and also uses one pass to git-diff. git-apply gives information on added,
removed files as well as which files are binary.
Removed the test for checking for matching binary files when deleting them
since git-apply happily deletes the file. This is matter of taste since we
allow some fuzz for text patches also.
Error handling was cleaned up, but not much tested.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
merge-file has the same syntax as RCS merge, but supports only the
"-L" option.
For good measure, a test is added, which is quite minimal, though.
[jc: further fix for compliation errors included.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The current check for symlinked reflogs was based on stat(2), which is
utterly embarrassing.
Fix it, and add a matching testcase.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Extend git-branch with the following options:
git-branch -m|-M [<oldbranch>] newbranch
The -M variation is required to force renaming over an exsisting
branchname.
This also indroduces $GIT_DIR/RENAME_REF which is a "metabranch"
used when renaming branches. It will always hold the original sha1
for the latest renamed branch.
Additionally, if $GIT_DIR/logs/RENAME_REF exists, all branch rename
events are logged there.
Finally, some testcases are added to verify the new options.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Johannes Schindelin