summaryrefslogtreecommitdiff
path: root/object.h
diff options
context:
space:
mode:
authorJohannes Schindelin <Johannes.Schindelin@gmx.de>2007-05-01 21:42:44 (GMT)
committerShawn O. Pearce <spearce@spearce.org>2007-05-02 17:22:34 (GMT)
commit775477aa1da94cb9fb9b9afdc217231a0cd42ac1 (patch)
treeb503ff64c120c824e60a30abcdb891b3396d3be3 /object.h
parentb5cc62f701abf8b903387a5d7c77a59f347d66fd (diff)
downloadgit-775477aa1da94cb9fb9b9afdc217231a0cd42ac1.zip
git-775477aa1da94cb9fb9b9afdc217231a0cd42ac1.tar.gz
git-775477aa1da94cb9fb9b9afdc217231a0cd42ac1.tar.bz2
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>
Diffstat (limited to 'object.h')
0 files changed, 0 insertions, 0 deletions