git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git-archive and tar options

From
René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date
Jul 18, 2011, 20:50 UTC
Message-ID
<4E249C8D.10107@lsrfire.ath.cx>
In-Reply-To
<4E248A2E.3090902@gmail.com>
Am 18.07.2011 21:31, schrieb Neal Kreitzinger:
Show 6 quoted lines
> 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.

Show 7 quoted lines
> 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? :)

Show 5 quoted lines
> 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é
Previous: Neal KreitzingerNext: Jakub Narebski
Message 13 of 22 in “git-archive and tar options”
  1. Neal KreitzingerJul 13, 2011
  2. Jeff KingJul 14, 2011
  3. René ScharfeJul 14, 2011
  4. Jeff KingJul 14, 2011
  5. René ScharfeJul 14, 2011
  6. Jeff KingJul 14, 2011
  7. Jakub NarebskiJul 14, 2011
  8. Junio C HamanoJul 14, 2011
  9. Jeff KingJul 14, 2011
  10. Junio C HamanoJul 14, 2011
  11. René ScharfeJul 15, 2011
  12. Neal KreitzingerJul 18, 2011
  13. René ScharfeJul 18, 2011
  14. Jakub NarebskiJul 14, 2011
  15. Neal KreitzingerJul 18, 2011
  16. René ScharfeJul 18, 2011
  17. Neal KreitzingerJul 19, 2011
  18. René ScharfeJul 19, 2011
  19. Neal KreitzingerJul 21, 2011
  20. Neal KreitzingerJul 21, 2011
  21. Andreas SchwabJul 14, 2011
  22. Sylvain RabotJul 19, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.