Commit Graph

8 Commits

Author SHA1 Message Date
Johannes Schindelin
df8cfac815 import-tars: Use the "Link indicator" to identify directories
Earlier, we used the mode to determine if a name was associated with
a directory. This fails, since some tar programs do not set the mode
correctly. However, the link indicator _has_ to be set correctly.

Noticed by Chris Riddoch.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-16 14:54:22 -04:00
Shawn O. Pearce
d966e6aa66 Properly handle '0' filenames in import-tars
Randal L. Schwartz pointed out multiple times that we should be
testing the length of the name string here, not if it is "true".
The problem is the string '0' is actually false in Perl when we
try to evaluate it in this context, as '0' is 0 numerically and
the number 0 is treated as a false value.  This would cause us
to break out of the import loop early if anyone had a file or
directory named "0".

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-07 21:13:40 -04:00
Johannes Schindelin
775477aa1d Teach import-tars about GNU tar's @LongLink extension.
This extension allows GNU tar to process file names in excess of the 100
characters defined by the original tar standard. It does this by faking a
file, named '././@LongLink' containing the true file name, and then adding
the file with a truncated name. The idea is that tar without this
extension will write out a file with the long file name, and write the
contents into a file with truncated name.

Unfortunately, GNU tar does a lousy job at times. When truncating results
in a _directory_ name, it will happily use _that_ as a truncated name for
the file.

An example where this actually happens is gcc-4.1.2, where the full path
of the file WeThrowThisExceptionHelper.java truncates _exactly_ before the
basename. So, we have to support that ad-hoc extension.

This bug was noticed by Chris Riddoch on IRC.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-02 13:22:34 -04:00
Junio C Hamano
d0c32b6339 Fix import-tars fix.
This heeds advice from our resident Perl expert to make sure
the script is not confused with a string that ends with /\n

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-29 01:34:59 -07:00
Johannes Schindelin
87859f3443 import-tars: be nice to wrong directory modes
Some tars seem to have modes 0755 for directories, not 01000755. Do
not generate an empty object for them, but ignore them.

Noticed by riddochc on IRC.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-04-28 20:01:36 -04:00
Michael Loeffler
c750da256a Use gunzip -c over gzcat in import-tars example.
Not everyone has gzcat or bzcat installed on their system, but
gunzip -c and bunzip2 -c perform the same task and are available
if the user has installed gzip support or bzip2 support.

Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-21 11:09:57 -05:00
Michael Loeffler
d63ea11594 import-tars: brown paper bag fix for file mode.
There is a bug with this $git_mode variable which should be 0644
or 0755, but nothing else I think.

Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-12 12:19:45 -05:00
Shawn O. Pearce
590dd4bfd2 tar archive frontend for fast-import.
This is an example fast-import frontend, in less than 100 lines
of Perl.  It accepts one or more tar archives on the command line,
passes them through gzcat/bzcat/zcat if necessary, parses out the
individual file headers and feeds all contained data to fast-import.
No temporary files are involved.

Each tar is treated as one commit, with the commit timestamp coming
from the oldest file modification date found within the tar.

Each tar is also tagged with an annotated tag, using the basename
of the tar file as the name of the tag.

Currently symbolic links and hard links are not handled by the
importer.  The file checksums are also not verified.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-08 15:37:53 -05:00