Re: git-archive and tar options

["René Scharfe" <rene.scharfe@lsrfire.ath.cx>]

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é