The latest GNU diff from CVS emits an empty line to express
an empty context line, instead of more traditional "single
white space followed by a newline". Do not get broken by it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
the repository argument for git-clone should be relative to $PWD
instead of the given target directory. The old behavior gave us
surprising success and you need a few minute to know why it worked.
GIT_DIR is already exported so no need to cd into $D. And this makes
$PWD for git-fetch-pack, which is the actual command to take the given
repository dir, the same as git-clone.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When whitespace or whitespace change was ignored, the function
xdl_recmatch() returned memcmp() style differences, which is wrong,
since it should return 0 on non-match.
Also, there were three horrible off-by-one bugs, even leading to wrong
hashes in the whitespace special handling.
The issue was noticed by Ray Lehtiniemi.
For good measure, this commit adds a test.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add symlink support to ZIP file creation, and a few tests.
This implementation sets the "version made by" field
(creator_version) to Unix for symlinks, only; regular files and
directories are still marked as originating from FAT/VFAT/NTFS.
Also set "external file attributes" (attr2) to 0 for regular
files and 16 for directories (FAT attribute), and to the file
mode for symlinks.
We could always set the creator_version to Unix and include the
mode, but then Info-ZIP unzip would set the mode of the extracted
files to *exactly* the value stored in attr2. The FAT trick
makes it apply the umask instead. Note: FAT has no executable
bit, so this information is not stored in the ZIP file.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When running tests with --verbose it is difficult to see where
one test starts and where it ends because everything is printed
in one big lump.
Fix that by printing one single newline between each test.
Signed-off-by: Martin Waitz <tali@admingilde.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "git log/diff --summary" imply recursive behaviour,
whose effect is summarized in one test output:
--- a/t/t4013/diff.diff-tree_--pretty_--root_--summary_initial
+++ b/t/t4013/diff.diff-tree_--pretty_--root_--summary_initial
@@ -5,7 +5,7 @@ Date: Mon Jun 26 00:00:00 2006 +0000
Initial
- create mode 040000 dir
+ create mode 100644 dir/sub
create mode 100644 file0
create mode 100644 file2
$
When a file is created in a subdirectory, we used to say just
the directory name only when that directory also was created,
which did not make sense from two reasons. It is not any more
significant to create a new file in a new directory than to
create a new file in an existing directory, and even if it were,
reportinging the new directory name without saying the actual
filename is not useful.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The command updated the cache without invalidating the cache
tree entries while removing an existing entry.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This test should be testing update-index --add, not git-add as the
latter is implemented in terms of the former.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This script creates two separate histories, A and B, each of
which does:
(A0, B0): create fileA and subdir/fileB
(A1, B1): modify fileA
(A2, B2): modify subdir/fileB
and then grafts them together to make B0 a child of A2. So
the final history looks like (time flows from top to bottom):
true parent touches subdir?
A0 none yes (creates it)
A1 A0 no
A2 A1 yes
B0 none yes (different from what's in A2)
B1 B0 no
B2 B1 yes
"git rev-list --parents --pretty=raw B2" would give "fake"
parents on the "commit " header lines while "parent " header
lines show the parent as recorded in the commit object (i.e. B0
appears to have A2 as its parent on "commit " header but there
is no "parent A2" header line in it).
When you have path limiters, we simplify history to omit
commits that do not affect the specified paths.
So "git rev-list --parents --pretty=raw B2 subdir" would return
"B2 B0 A2 A0" (because B1 and A1 do not touch the path). When
it does so, the "commit " header lines have "fake" parents
(i.e. B2 appears to have B0 as its parent on "commit " header),
but you can still get the true parents by looking at "parent "
header.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I've seen some users get into situtations where their HEAD
symbolic-ref is pointing at a non-existant ref. (Sometimes this
happens during clone when the remote repository lacks a 'master'
branch.) If this happens the user is unable to use git-checkout
to switch branches as there is no prior commit to merge from.
So instead of giving the user low-level errors about how HEAD
can't be resolved and how not a single revision was given change
the type of checkout to be a force and go through with the user's
request anyway.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user has configured core.filemode=0 then we shouldn't set
the execute bit in the index when adding a new file as the user
has indicated that the local filesystem can't be trusted.
This means that when adding files that should be marked executable
in a repository with core.filemode=0 the user must perform a
'git update-index --chmod=+x' on the file before committing the
addition.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch also adds test cases from Linus and Junio.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This renames merge-recursive written in Python to merge-recursive-old,
and makes merge-recur as a synonym to merge-recursive. We do not remove
merge-recur yet, but we will remove merge-recur and merge-recursive-old
in a few releases down the road.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When there are single-character filenames in the test directory,
the shell tries to expand regexps meant for tr.
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: with a fix to config handling in t5400 test, which took
annoyingly long to diagnose.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I had a hard time figuring out why this test was failing with
the packed-refs update without running it under "sh -x". This
makes output from "sh t1400-update-ref.sh -v" more descriptive.
Updating other tests would be a good janitorial task.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Historically we did not allow binary patch applied without an
explicit permission from the user, and this flag was the way to
do so. This makes the flag a no-op by always allowing binary
patch application.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If GIT_TRACE is set to an absolute path (starting with a
'/' character), we interpret this as a file path and we
trace into it.
Also if GIT_TRACE is set to an integer value greater than
1 and lower than 10, we interpret this as an open fd value
and we trace into it.
Note that this behavior is not compatible with the
previous one.
We also trace whole messages using one write(2) call to
make sure messages from processes do net get mixed up in
the middle.
This patch makes it possible to get trace information when
running "make test".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now if GIT_TRACE is set to an integer value greater than 1
and lower than 10, we interpret this as an open fd value
and we trace into it. Note that this behavior is not
compatible with the previous one.
We also trace whole messages using one write(2) call to
make sure messages from processes do net get mixed up in
the middle.
It's now possible to run the tests like this:
GIT_TRACE=9 make test 9>/var/tmp/trace.log
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The intention of the test seems to be to build a long chain of
clones that locally borrow objects from their parents and see the
system give up dereferencing long chains. There were two problems:
(1) it did not test the right repository;
(2) it did not build a chain long enough to trigger the limitation.
I do not think it is a good test to make sure the limitation the
current implementation happens to have still exists, but that is
a topic at a totally different level.
At least this fixes the broken test.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since the normalized basename of "." is "", the check for directory
failed erroneously.
Noticed by Fredrik Kuivinen.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With the new flag "--reject", hunks that do not apply are sent to
the standard output, and the usable hunks are applied. The command
itself exits with non-zero status when this happens, so that the
user or wrapper can take notice and sort the remaining mess out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
As noted by Fredrik Kuivinen, without this patch, git-mv fails on
git-mv README README-renamed
because "README" is a prefix of "README-renamed".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The binary patch test needs to be made more careful not to have
the postimage blob in the repository in which the patch is applied
Signed-off-by: Junio C Hamano <junkio@cox.net>
By default, the command shows pathnames relative to the current
directory. Use --full-name (the same flag to do so in ls-files)
if you want to see the full pathname relative to the project root.
This makes it very pleasant to run in Emacs compilation (or
"grep-find") buffer.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The internal representation of the result is counted string
(i.e. char *buf and ulong size), which is fine for writing out
to regular file, but throwing the buf at symlink(2) was a
no-no.
Reported by Willy Tarreau.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to find the first match of the pattern and then if the
match is not for the entire word, declared that the whole line
does not match.
But that is wrong. The command "git grep -w -e mmap" should
find that a line "foo_mmap bar mmap baz" matches, by tring the
second instance of pattern "mmap" on the same line.
Problems an earlier round of "fix" had were pointed out by Morten
Welinder, which have been incorporated in the t7002 tests.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We still have too few of them, but we have to start from somewhere.
The general rule is to make tests easy to debug when run with -v (notice
use of seemingly useless echo everywhere in the new tests).
Signed-off-by: Junio C Hamano <junkio@cox.net>
The cmd_usage() routine was causing warning messages due to a NULL
format parameter being passed in three out of four calls. This is a
problem if you want to compile with -Werror. A simple solution is to
simply remove the GNU __attribute__ format pragma from the cmd_usage()
declaration in the header file. The function interface was somewhat
muddled anyway, so re-write the code to finesse the problem.
[jc: this incidentally revealed that t9100 test assumed that the output
from "git help" to be fixed in stone, but this patch lower-cases
"Usage" to "usage". Update the test not to rely on "git help" output.]
Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
These changes were originally part of the next patch, but have been
split out since they were peripheral to the main purpose of that patch.
- update comment describing the signature format to reflect
the current code.
- remove trailing \n in calls to error(), since a \n is already
provided by error().
- remove redundant call to get_sha1_hex().
- call sha1_to_hex(sha1) to convert to ascii, rather than attempting
to print the raw sha1.
The new tests provide a regression suite to support the modifications
to git-mktag in this and the next patch.
Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The t8001-annotate.sh test claimed all tests pass, when in fact
the git-annotate perl script failed to run! (prior to fixing the
script to work with perl 5.5).
Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Alex Riesen (raa.lkml@gmail.com) recently observed that git branch
would fail with no error message due to unexpected situations with
regards to refs. For example, if .git/refs/heads/gu is a file but
"git branch -b refs/heads/gu/fixa HEAD" was invoked by the user
it would fail silently due to refs/heads/gu being a file and not
a directory.
This change adds a test for trying to create a ref within a directory
that is actually currently a file, and adds error printing within
the ref locking routine should the resolve operation fail.
The error printing code probably belongs at this level of the library
as other failures within the ref locking, writing and logging code
are also currently at this level of the code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The generated binary patch was _not_ binary -- earlier I made
the --full-index flag to imply binary patch generation to the diff
machinery, but later we made it independent from --binary (although
the latter implies the former).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the builtin mv for the test which Josef provided, and also
fixes moving directories into existing directories, as noted by Jon Smirl.
In case the destination exists, fail early (this cannot be overridden
by -f).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If dir2 already exists, git-mv should move dir1 _into_dir2/.
Noticed by Jon Smirl.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Linus:
get_pathspec() does turn '.' into an empty string (which is
correct - git internally does _not_ ever understand the notion of
"." as the current working directory), but it doesn't ever do the
optimization of noticing that a pathspec that consists solely of
an empty string is "equivalent" to an empty pathspec.
The test is to ensure that this behaviour stays.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano