From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
Cc: Nguyen Thai Ngoc Duy <pclouds@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH v2 3/3] archive: do not read .gitattributes in working directory
Date: Wed, 15 Apr 2009 17:26:52 -0700 [thread overview]
Message-ID: <7vr5ztpho3.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <49E4FCF8.3050207@lsrfire.ath.cx> (René Scharfe's message of "Tue, 14 Apr 2009 23:15:36 +0200")
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Junio C Hamano schrieb:
> ...
>> Ah, bootstrap_attr_stack() and prepare_attr_stack() still assume that you
>> won't be doing any per-level attributes in a bare repository because the
>> concept of attributes is inherently tied to having a work tree from their
>> point of view.
>>
>> How about this "mostly re-indent with four line removal" patch?
>
> Plus the following (on top of Duy's GIT_ATTR_INDEX patch)?
Actually, the "mostly re-indent" patch breaks things for normal users that
expect the attributes never kicks in when you are doing things in a bare
repository as-is.
> diff --git a/attr.c b/attr.c
> index f5917de..cce561b 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -672,6 +672,8 @@ int git_checkattr(const char *path, int num, struct git_attr_check *check)
> void git_attr_set_direction(enum git_attr_direction new, struct index_state *istate)
> {
> enum git_attr_direction old = direction;
> + if (is_bare_repository())
> + new = GIT_ATTR_INDEX;
> direction = new;
> if (new != old)
> drop_attr_stack();
This looks _conceptually_ wrong.
I think your patch came from the fact that check_updates() unconditionally
calls git_attr_set_direction() without checking o->update, and I think it
is a bug in check_updates().
A bare repository is by definition without a work tree, and we shouldn't
be reading the index in general. I wouldn't go as far to say that a bare
repository should not have the index file, because people often clone
forgetting the --bare option and manually convert that to a bare
repository, and they forget to remove the index that is never used.
... thinks a bit more ...
I think codepaths that make calls to git_attr_set_direction() inside
is_bare_repository() are special already. If we were to teach check-attr
how to check attributes for paths _inside a given tree-ish_, most likely
the implementation would be similar to what Duy did for archive; read the
tree into in-core index, set direction to the INDEX, and start using the
attribute mechanism.
So I think we'd rather not have the patch to force GIT_ATTR_INDEX in
set_direction(); if anything, the patch should say something like "if we
are in a bare repository and the new direction is not INDEX, it is a
programming error".
Instead, such specialized codepaths should call set_direction() itself,
perhaps after reading the tree-ish into the in-core index. And we should
fix the "mostly re-indent" patch not to remove the conditional, but make
the conditional to check "If in a bare repository and the direction is not
explicitly set to INDEX, do not use the attributes".
next prev parent reply other threads:[~2009-04-16 0:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-09 7:01 [PATCH v2 0/3] support "in-tree attributes" for git-archive Nguyễn Thái Ngọc Duy
2009-04-09 7:01 ` [PATCH v2 1/3] archive: add shortcuts for --format and --prefix Nguyễn Thái Ngọc Duy
2009-04-09 7:01 ` [PATCH v2 2/3] attr: add GIT_ATTR_INDEX "direction" Nguyễn Thái Ngọc Duy
2009-04-09 7:01 ` [PATCH v2 3/3] archive: do not read .gitattributes in working directory Nguyễn Thái Ngọc Duy
2009-04-09 8:49 ` Junio C Hamano
2009-04-09 10:53 ` Nguyen Thai Ngoc Duy
2009-04-11 19:22 ` Junio C Hamano
2009-04-13 10:41 ` René Scharfe
2009-04-13 12:18 ` René Scharfe
2009-04-13 13:08 ` René Scharfe
2009-04-14 5:11 ` Junio C Hamano
2009-04-14 21:15 ` René Scharfe
2009-04-16 0:26 ` Junio C Hamano [this message]
2009-04-09 8:47 ` [PATCH v2 1/3] archive: add shortcuts for --format and --prefix Junio C Hamano
2009-04-09 10:38 ` Nguyen Thai Ngoc Duy
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=7vr5ztpho3.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=rene.scharfe@lsrfire.ath.cx \
/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).