| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Integrates support for hard links from the change made in upstream git
back in 2016.
Below is the body of the upstream commit
(04e0869876f726d5af9ac901911781d440e6aed2):
Previously, we simply treated hard links as if they were plain files
with size 0, ignoring the link type "1" and hence the link target.
What we should do instead, of course, is to use the link target to get
at the import mark for the contents, even if we cannot recreate the hard
link per se, as Git has no concept of hard links.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tar importer in `contrib/fast-import/import-tars.perl` has a very
convenient feature: if _all_ paths stored in the imported `.tar` start
with a common prefix, e.g. `git-2.26.0/` in the tar at
https://github.com/git/git/archive/v2.26.0.tar.gz, then this prefix is
stripped.
This feature makes a ton of sense because it is relatively common to
import two or more revisions of the same project into Git, and obviously
we don't want all files to live in a tree whose name changes from
revision to revision.
Now, the problem with that feature is that it breaks down if there is a
`pax_global_header` "file" located outside of said prefix, at the top of
the tree. This is the case for `.tar` files generated by Git's very own
`git archive` command: it inserts that header, and `git archive` allows
specifying a common prefix (that the header does _not_ share with the
other files contained in the archive) via `--prefix=my-project-1.0.0/`.
Let's just skip any global header when importing `.tar` files into Git.
Note: this global header might contain useful information. For example,
in the output of `git archive`, it lists the original commit, which _is_
useful information. A future improvement to the `import-tars.perl`
script might be to include that information in the commit message, or do
other things with the information (e.g. use `mtime` information
contained in the global header as date of the commit). This patch does
not prevent any future patch from making that happen, it only prevents
the header from being treated as if it was a regular file.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |
|
|
|
| |
This seems like a more obvious to look for such information,
and it's also where the GPL says we should mention changes.
|
| |
|
|
|
|
| |
These are based on scripts in the git project, which we noted but
didn't include a copyright statement for. Put copyright notices
(including for our changes) in those files and in LICENSE.
|
| |
|
|
|
|
| |
The $commit_time variable is unused since commit cf4a0dff36819 "Make
tarball lorries reproducible", but it confused me into thinking the
issue was still unfixed. Delete it to avoid confusing anyone else.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes the tar files will contain PAX extended headers to deal with
cases where the information needed doesn't fit initial header.
One of these cases is when the path is larger than 100 characters. An
extended header will appear before the block including the contents of
this file, including information about the entire path.
The PAX extended headers contain one or multiple records constructed as
follows:
"%d %s=%s\n", <length>, <keyword>, <value>
This commit makes sure that we always read the extended header blocks,
and in the case of finding one, we parse its records looking for 'path'
information. If this information is found, is stored for the next
iteration.
As a side effect, this commit also fixes a bug where we weren't ignoring
the extended header contents because the truncated path was ending on '/'
and the script was skipping any actions given that it thought that it
was a folder (and it wasn't).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bsd tar stores file attributes as extended headers,
which are ignored by gnu tar. The tar importer currently
treats these headers as regular files, so regular files
containing attribute data are created on extraction even
though they never existed at archive creation.
This can be a problem for CPAN imports, some CPAN distributions
are created using bsd tar, the extended headers in these archives
result in a modified directory structure, e.g. where the structure
on the developer's machine would be
Foo:
META.json
META.yml
Makefile.PL
...
in trove we could have,
Foo:
Foo/
Foo/META.json
Foo/META.yml
Foo/Makefile.PL
PAXHeader/
PAXHeader/Foo
...
this structure causes the default build-commands to fail because they
expect to find Makefile.PL in the repo's root dir.
Change-Id: Ia8f90c3be7b31f7a4ac774022cb606fc1c57c002
|
| |
|
|
|
|
|
| |
We don't want the sha to depend on where the lorry was imported from
or the time at which the lorry occurred, or the user's environment.
Change-Id: Iccc54f358a1a6133438984e769485b702ebb1a2e
|
|
|
This patch makes Lorry always create bare repositories where it can (Note that
it cannot for CVS imports) and to create tarballs of bare repositories (if not
disabled) which will be more efficient than bundles for creation and cloning.
We may be able to disable bundles later.
|
