Hi!
The git-archive man page indicates that if the --prefix option is passed to
git-archive, it is compulsory to end the prefix with a "/"
git archive [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>] ...
As a matter of fact, the archiver behaves quite strangely if that slash is
missing. Files in the root of the working dir are added to the archive with
their own name modified by the prefix and the same happens for working dir
sub-directories. However, no file present in the sub-directories, nor
sub-sub-directories are added.
I would like to know if there some reason why a trailing "/" is not added
automatically to the prefix when it is missing and the prefix is not empty.
Would that break anything?
Thanks!
Sergio
From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:29
Sergio Callegari [off-list ref] writes:
The git-archive man page indicates that if the --prefix option is passed to
git-archive, it is compulsory to end the prefix with a "/"
No, it does not have to.
$ git archive --prefix=v1.6.0- v1.6.0 Makefile | tar xf -
$ make -f v1.6.0-Makefile
This is consistent with the way the same --prefix option can be used with
checkout-index. e.g. to swap Makefile in work tree and in the index:
$ edit Makefile
$ git checkout-index --prefix=old- Makefile
$ git update-index Makefile
$ mv old-Makefile Makefile
These may or may not be useful examples, but this feature has been with us
for a long time. I wouldn't be surprised if removing the ability to
archive or checkout with filename prefix (not leading directory path
prefix) causes grief to existing scripts of people.
From: René Scharfe <hidden> Date: 2016-06-15 22:47:29
Sergio Callegari schrieb:
Hi!
The git-archive man page indicates that if the --prefix option is passed to
git-archive, it is compulsory to end the prefix with a "/"
git archive [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>] ...
As a matter of fact, the archiver behaves quite strangely if that slash is
missing. Files in the root of the working dir are added to the archive with
their own name modified by the prefix and the same happens for working dir
sub-directories. However, no file present in the sub-directories, nor
sub-sub-directories are added.
The latter is a bug.
I would like to know if there some reason why a trailing "/" is not added
automatically to the prefix when it is missing and the prefix is not empty.
Would that break anything?
The --prefix option is intended to add a string to the beginning (i.e. "to
prefix") of the name of the archive entries. I'm not sure if there's a use
case for anything else than adding a fake directory for all entries to live
in (thus requiring a trailing slash), but I also don't see why we should
disallow it.
The following patch fixes handling of prefixes without trailing slashes by
taking it out of the hands of get_pathspec() and read_tree_recursive() --
which can only handle prefixes that are path components -- and adding the
prefix later, in write_archive_entry().
Signed-off-by: Rene Scharfe <redacted>
---
archive.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
The git-archive man page indicates that if the --prefix option is passed to
git-archive, it is compulsory to end the prefix with a "/"
Yeah, that part is intentional. And:
As a matter of fact, the archiver behaves quite strangely if that slash is
missing. Files in the root of the working dir are added to the archive with
their own name modified by the prefix and the same happens for working dir
sub-directories.
So far so good. But
However, no file present in the sub-directories, nor sub-sub-directories
are added.
Ok, that is a bug. It's supposed to just add the prefix to everything, and
it sounds like it's simply broken. I wonder how long it's been broken?
Perhaps forever.
I would like to know if there some reason why a trailing "/" is not added
automatically to the prefix when it is missing and the prefix is not empty.
Would that break anything?
It really was meant to be useful to prefix things without forcing a
directory structure. IOW, being able to use "--prefix=compat-" and just
have everything unpack with their own names, but with the prefix.
Whether anybody uses that, and whether it's worth it, I can't say.
Linus
The git-archive man page indicates that if the --prefix option is passed to
git-archive, it is compulsory to end the prefix with a "/"
No, it does not have to.
$ git archive --prefix=v1.6.0- v1.6.0 Makefile | tar xf -
$ make -f v1.6.0-Makefile
Thanks... I now see better all the possible uses.
This is consistent with the way the same --prefix option can be used with
checkout-index. e.g. to swap Makefile in work tree and in the index:
$ edit Makefile
$ git checkout-index --prefix=old- Makefile
$ git update-index Makefile
$ mv old-Makefile Makefile
These may or may not be useful examples, but this feature has been with us
for a long time. I wouldn't be surprised if removing the ability to
archive or checkout with filename prefix (not leading directory path
prefix) causes grief to existing scripts of people.
That's why I asked btw. I did not want to start experimenting
modification like auto adding a "/"
after the prefix without knowing whether they could have limited some
other uses or broken some
consistency. I now see they would do.
I guess the bug in using --prefix on a worktree with subdirs without
specifying a path is not specific
to git archive, then.
Sergio
From: René Scharfe <hidden> Date: 2016-06-15 22:47:29
Sergio Callegari schrieb:
I guess the bug in using --prefix on a worktree with subdirs without
specifying a path is not specific to git archive, then.
The bug should be limited to archive; after my patch all calls to
read_tree_recursive() specify an empty base parameter (except in tree.c,
where the function itself lives).
René