public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
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

  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$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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