From: Toby Corkindale <toby.corkindale@rea-group.com>
To: git@vger.kernel.org
Subject: Re: .git/info/attributes not cloned
Date: Thu, 27 Mar 2008 15:23:27 +1100 [thread overview]
Message-ID: <47EB213F.1020503@rea-group.com> (raw)
In-Reply-To: <20080327033341.GB5417@coredump.intra.peff.net>
Jeff King wrote:
> On Thu, Mar 27, 2008 at 02:08:30PM +1100, Toby Corkindale wrote:
>
>> If one creates a .git/info/attributes file in a Git repo, it will not be
>> present in cloned repos.
>> I don't know if this is a bug or not, but it /seems/ wrong behaviour to
>> me, and reading from the manual pages.
>
> It is not a bug. The .gitattributes file in your working directory _is_
> cloned, and that is the right place to put things that you want to be
> revision-controlled and used in every repo. The .git/info/attributes
> file is for attributes that are purely local to that repo. This is
> similar to the split between .git/info/exclude and .gitignore.
Ah, OK.
I was hoping not to use .gitattributes, as then the attributes are
ignored when doing something like:
git archive --remote=example.com:/path/to/repo release/v2.1 | tar xf -
> Can you point out which part of the manual gave the wrong impression (or
> better yet, submit a patch making it more clear)?
Now that you've mentioned the difference between info/exclude and
.gitignore, I see that in the docs/user-manual.html it is said:
"If you wish the exclude patterns to affect only certain repositories
(instead of every repository for a given project), you may instead put
them in a file in your repository named .git/info/exclude, or in any
file specified by the core.excludesfile configuration variable."
That gives a clue that the /info/ files are repo-specific.
However in gitignore(5) and gitattributes(5), there is no explanation of
this - it simply mentions that the info version is a higher priority
than the .git{ignore,attributes} version.
I suggest that the individual docs/man-pages should mention that too.
I'll submit a patch in a separate email, as long as I'm not still
misunderstanding the mechanism.
Is there a recommended way to make attributes apply to commands run on a
remote repository, or is that a different bug?
thanks,
Toby
next prev parent reply other threads:[~2008-03-27 4:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-27 3:08 .git/info/attributes not cloned Toby Corkindale
2008-03-27 3:33 ` Jeff King
2008-03-27 4:23 ` Toby Corkindale [this message]
2008-03-27 4:29 ` Jeff King
2008-03-27 4:48 ` Toby Corkindale
2008-03-27 4:53 ` Jeff King
2008-03-28 5:10 ` [BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned) Toby Corkindale
2008-03-28 12:22 ` Johannes Schindelin
2008-03-28 13:02 ` Jakub Narebski
2008-03-28 13:22 ` Johannes Schindelin
2008-03-31 2:47 ` Jeff King
2008-03-31 3:07 ` [BUG?] git-archive ignores remote .gitattributes Junio C Hamano
2008-04-10 4:14 ` Toby Corkindale
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=47EB213F.1020503@rea-group.com \
--to=toby.corkindale@rea-group.com \
--cc=git@vger.kernel.org \
/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.