Makefile records paths to a few programs in GIT-BUILD-OPTIONS file. These
paths need to be quoted twice: once to protect specials from the shell
that runs the generated GIT-BUILD-OPTIONS file, and again to protect them
(and the first level of quoting itself) from the shell that runs the
"echo" inside the Makefile.
You can test this by trying:
$ ln -s /bin/tar "$HOME/Tes' program/tar"
$ make TAR="$HOME/Tes' program/tar" test
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Paths marked with this attribute are not output to git-archive
output.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output of 'tar tv' varies from system to system. In
particular, the t5000 was expecting to parse the date from
something like:
-rw-rw-r-- root/root 0 2008-05-13 04:27 file
but FreeBSD's tar produces this:
-rw-rw-r-- 0 root root 0 May 13 04:27 file
Instead of relying on tar's output, let's just extract the
file using tar and stat the result using perl.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ulrik Sverdrup noticed that git-archive doesn't correctly apply the attribute
export-subst when the option --prefix is given, too.
When it checked if a file has the attribute turned on, git-archive would try
to look up the full path -- including the prefix -- in .gitattributes. That's
wrong, as the prefix doesn't need to have any relation to any existing
directories, tracked or not.
This patch makes git-archive ignore the prefix when looking up if value of the
attribute export-subst for a file.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before the strbuf conversion, result was a char pointer. The if
statement checked for it being not NULL, which meant that no
"$Format:...$" string had been found and no replacement had to be
made. format_subst() returned NULL in that case -- the caller
then simply kept the original file content, as it was unaffected
by the expansion.
The length of the string being 0 is not the same as the string
being NULL (expansion to an empty string vs. no expansion at all),
so checking result.len != 0 is not a full replacement for the old
NULL check.
However, I doubt the subtle optimization explained above resulted
in a notable speed-up anyway. Simplify the code and add the tail
of the file to the expanded string unconditionally.
[jc: added a test to expose the breakage this fixes]
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As suggested by Junio and Johannes, change the name of the former
attribute specfile to export-subst to indicate its function rather
than purpose and to make clear that it is not applied to working tree
files.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As suggested by Johannes, --pretty=format: placeholders in specfiles
need to be wrapped in $Format:...$ now. This syntax change restricts
the expansion of placeholders and makes it easier to use with files
that contain non-placeholder percent signs.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add support for a new attribute, specfile. Files marked as being
specfiles are expanded by git-archive when they are written to an
archive. It has no effect on worktree files. The same placeholders
as those for the option --pretty=format: of git-log et al. can be
used.
The attribute is useful for creating auto-updating specfiles. It is
limited by the underlying function format_commit_message(), though.
E.g. currently there is no placeholder for git-describe like output,
and expanded specfiles can't contain NUL bytes. That can be fixed
in format_commit_message() later and will then benefit users of
git-log, too.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
unzip -v on (at least) Ubuntu prints a screenful of version info
to stdout. Get rid of it since we only want to know if unzip is
installed or not.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
As noted by Junio, --format=tar should be assumed if no format
was specified.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 64edf4b2 cleaned up the initialization of git-archive,
at the cost of 'git-archive --list' now requiring a git repo.
This patch reverts the cleanup and documents the requirement
for this particular dirtyness in a test.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
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>
... to store parts of the path, if possible. This allows us to avoid
writing extended headers in certain cases (long pathes can only be
split at '/' chars).
Also adds a file to the test repo with a 100 chars long directory name.
Even old versions of tar that don't understand POSIX extended headers
should be able to handle this testcase.
Btw.: The longest path in the kernel tree currently has 70 chars.
Together with a 30 chars long prefix this would already cross the
field limit of 100 chars.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- The location of openssl development files got customizable.
- The location of iconv development files got customizable.
- Pass $TAR down to t5000 test so that the user can override with
'gmake TAR=gtar'.
- Solaris 'bc' does not seem to grok "define abs()". There is no
reason to use bc there -- expr would do.
Signed-off-by: Junio C Hamano <junio@twinsun.com>
As promised, this is the "big tool rename" patch. The primary differences
since 0.99.6 are:
(1) git-*-script are no more. The commands installed do not
have any such suffix so users do not have to remember if
something is implemented as a shell script or not.
(2) Many command names with 'cache' in them are renamed with
'index' if that is what they mean.
There are backward compatibility symblic links so that you and
Porcelains can keep using the old names, but the backward
compatibility support is expected to be removed in the near
future.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It seems that the localtime() libc routine doesn't care for finding a TZ
that's empty. It's ok with TZ not being set. Setting the TZ to GMT allowed
these tests to pass.
$ uname -v
Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC
Signed-off-by: Brad Roberts <braddr@puremagic.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We use 'A' for added files instead of 'N' to make the it
visually easier to distinguish from 'M' now.
While we are at it, make the test scripts executable. Yes, I
know it does not matter because t/Makefile runs them explicitly
with "sh tXXXX-blah.sh", but being consistent is always better.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Unset TZ to force GMT in test #4 and add a set of parens around
the length function in the awk script.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
Acked-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
git-tar-tree: remove tests of long path handling out of t5000-tar-tree.sh
and make test script cope with tar programs displaying file modification
date as hh:mm (newer variants show it as hh:mm:ss).
This makes the test cover only basic functionality that is expected to
be handled even by older tar programs. Tests for long filenames (which
require pax extended headers) can be added separately.
I ran this test successfully with GNU tar 1.13, 1.14 and 1.15.1.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>