René Scharfe <l.s.r@xxxxxx> writes: >> I offhand do not know how well it would mix with --strip-components >> if we leave the leading "../". > > Not too well when entries from $PWD are shortened and mixed with ones > from elsewhere that aren't. But that seems like a strange thing to do. Yes, it is a strange thing to do. > If two sub-trees are needed then git archive should be started in a > shared parent directory higher up. > >> But it certainly would be nice if we somehow: >> >> * can keep the current behaviour where "git -C sub archive" records >> paths relative to "sub" for backward compatibility. > > Right. That's what relative_path() provides in the patch. > >> * fail loudly when "git -C sub archive <pathspec>" makes us use >> "../" prefix because <pathspec> goes above the $PWD for backward >> compatibility and sanity. > > Without the patch this fails, but are there really people that depend on > it failing? We could certainly forbid it, but do we need to? I dunno. It was an obvious way to avoid having to think about interaction with --strip-components and "../", but there certainly may be other solutions for it people can think of. Also on the receiving end, don't people get upset to see that their "tar xf" escapes the directory they just created only to extract the tarball? >> * with --some-option, make "git -C sub archive --some-option :/" >> act exactly like "git archive :/". > > Perhaps I'm reading this too literally, but it would be easier to remove > "-C sub" from that command. Or to add "-C $(git rev-parse --show-cdup)". > We could add a shortcut for that (see patch below). More like $ cd some/deep/place ... work work work $ git archive --full-tree :/other :/hier :/archy is what I had in mind. Without --full-tree, due to the first bullet point above, paths in our archive are relative to some/deep/place. Thanks.
