Re: git-archive and tar options

Am 18.07.2011 21:31, schrieb Neal Kreitzinger:

In regards to use cases in general, my impression is that git-archive is
for producing archives useful for deployment.  The target deployed
structure may vary so expecting the source git repo to reflect this is
unfeasable.  It seems like utilizing the local tar installation would
effect the necessary transformations. I'm not sure what the source and
target tar version disparity problems might me.

Direct deployment is not an _intended_ use case, but I see that it might
be useful for that, especially with scripting languages.

I'm not sure I like tar's --transform option, though.  This seems to be
too heavy a solution.  For your example it would be enough to support
multiple tree arguments (with their own respective prefixes) in one go.

A practical problem with the pax header is that its only useful if you
still have the archive.  Archives usually get deleted after being
extracted.  Therefore, an option to also generate (and add to the
archive) an automatic "VERSION.TXT" file of some sort which specifies
the context of the archive would be much more useful.  It would need its
own --prefix option because oftentimes it would be dynamically generated
based on the git-archive request.

The attribute export-subst with its $Format:$ expansion is intended to
be used for such version files.  It still lacks the ability to produce
git-describe-style version strings, but commit hashes can be used instead.

Another use case is that it seems like there should also be the option
to only tar the objects changed between a specified range of commits.
However, I'm not sure if tar can handle deletions (moves, deletions,
renames) upon extraction in this context.

Well, you could build a list of paths using git log --name-status or
similar and feed that to git archive.  If you want to keep a directory
in sync with a repo, why not use git checkout, though? :)

I can see that my use cases are something that I can script myself, but
to do so it seems like I would be better off using a non-bare repo
checkout as an intermediary.  If that is what I am expected to do then I
am not sure what the usefulness of git-archive is intended to be.  Maybe
I don't understand what others use it for.

The primary use case is to create source code archives that people can
download, build and deploy who are not interested in downloading the
whole history or in using git at all.

René