From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Junio C Hamano <gitster@pobox.com>
Cc: Francois Marier <fmarier@gmail.com>,
git@vger.kernel.org, Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Subject: Re: [PATCH] git-archive documentation: .gitattributes must be committed
Date: Wed, 10 Feb 2010 21:00:03 +0100 [thread overview]
Message-ID: <4B731043.6010108@lsrfire.ath.cx> (raw)
In-Reply-To: <7v1vgsao21.fsf@alter.siamese.dyndns.org>
Am 10.02.2010 20:27, schrieb Junio C Hamano:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>>> +The .gitattributes file must be present in the named tree for it to take
>>> +effect. Uncommitted attributes will not be considered in exports.
>>> +
>>> EXAMPLES
>>> --------
>>> git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)::
>>
>> Yeah, the description of --worktree-attributes is a bit terse. The
>> lines you add make it appear almost as if this switch doesn't exist,
>> though; perhaps add a "unless --worktree-attributes is given" or similar
>> to one of the new sentences?
>
> My impression has always been that people use attributes with archive more
> often to _tweak_ how the archive is produced after the fact, and they do
> so by modifying checked out .gitattributes (or $GIT_DIR/info/attributes)
> than allowing a possibly stale .gitattributes file etched in stone^Wtree
> being archived. So in that sense, probably --worktree-attributes should
> have been the default.
That was the case up to ba053ea9 (April 2009, archive: do not read
.gitattributes in working directory). I think that the current
behaviour makes sense because it provides a repeatable default.
René
next prev parent reply other threads:[~2010-02-10 20:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-10 2:51 [PATCH] git-archive documentation: .gitattributes must be committed Francois Marier
2010-02-10 19:07 ` René Scharfe
2010-02-10 19:27 ` Junio C Hamano
2010-02-10 19:33 ` Junio C Hamano
2010-02-10 20:00 ` René Scharfe [this message]
2010-02-10 20:18 ` Junio C Hamano
2010-02-10 20:33 ` Junio C Hamano
2010-02-11 3:48 ` Francois Marier
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=4B731043.6010108@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=fmarier@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.