From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, Neal Kreitzinger <neal@rsss.com>,
git@vger.kernel.org
Subject: Re: git-archive and tar options
Date: Fri, 15 Jul 2011 22:59:46 +0200 [thread overview]
Message-ID: <4E20AA42.7000003@lsrfire.ath.cx> (raw)
In-Reply-To: <7vwrfk1lv3.fsf@alter.siamese.dyndns.org>
Am 15.07.2011 01:30, schrieb Junio C Hamano:
> Jeff King <peff@peff.net> writes:
>
>>> Why?
>>>
>>> The tree you are writing out that way look very different from what is
>>> recorded in the commit object. What's the point of introducing confusion
>>> by allowing many tarballs with different contents written from the same
>>> commits with such tweaks all labelled with the same pax header?
>>
>> See my later message. I think it depends on how the embedded id is used.
>> Is it to say "this represents the tree of this git commit"? Or is it to
>> help people who later have a tarball and have no clue which commit it
>> might have come from?
>
> People, who have no clue which part of the subtree was extract and what
> leading path was added, would still have to wonder where the tree came
> from even with the embedded id. Without your patch, if the tarball has an
> embedded id, wouldn't they at least be able to assume it is the whole
> thing of that commit? If you label a randomly mutated tree with the same
> label, you cannot tell the genuine one from manipulated ones.
>
> Not that I have strong opinions on this, either, but that is what I meant
> by "_introducing_" confusion.
When we started to write the ID into generated archives, there was only
git-tar-tree and no <rev>:<path> syntax. It would write the ID only if
it was given a commit and not if it got a tree or if the user started it
from a subdirectory. The result was that only the full tree of a commit
was branded with the commit ID.
Now we have git archive, a more flexible command line syntax all around,
path limiting as well as attributes that can affect the contents of the
files in the archive. Back then the commmit ID was sufficient as a
concise and canonical label of the archive contents, but now things are
a bit more complicated.
Which use cases are we aiming for? Do we want to include all of the
command line arguments (with revs resolved to SHA1-IDs)? Only those
that modify archive contents? And any applied attributes? Or do we
want to get stricter and only write the commit ID if a full unchanged
tree of a commit is being archived?
René
next prev parent reply other threads:[~2011-07-15 21:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-13 23:34 git-archive and tar options Neal Kreitzinger
2011-07-14 1:56 ` Jeff King
2011-07-14 17:16 ` René Scharfe
2011-07-14 17:27 ` Jeff King
2011-07-14 17:45 ` René Scharfe
2011-07-14 18:18 ` Jeff King
2011-07-14 19:12 ` Jakub Narebski
2011-07-14 21:23 ` Junio C Hamano
2011-07-14 21:25 ` Jeff King
2011-07-14 23:30 ` Junio C Hamano
2011-07-15 20:59 ` René Scharfe [this message]
2011-07-18 19:31 ` Neal Kreitzinger
2011-07-18 20:50 ` René Scharfe
2011-07-14 21:38 ` Jakub Narebski
2011-07-18 18:13 ` Neal Kreitzinger
2011-07-18 20:50 ` René Scharfe
2011-07-19 0:12 ` Neal Kreitzinger
2011-07-19 17:56 ` René Scharfe
2011-07-21 2:13 ` Neal Kreitzinger
2011-07-21 16:59 ` Neal Kreitzinger
2011-07-14 17:48 ` Andreas Schwab
2011-07-19 20:10 ` Sylvain Rabot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E20AA42.7000003@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=neal@rsss.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).