.git/info/attributes not cloned

.git/info/attributes not cloned

[Toby Corkindale]

Hi.
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.

This shell script demonstrates the issue:

#!/bin/bash
mkdir testgit
cd testgit
mkdir original
cd original
git init --shared
echo -e "# gitattributes(5) file\n*.pm ident" > .git/info/attributes
echo "# \$Ident\$" > example.pm
git add example.pm
git commit -m "initial commit"
cd ..
git clone --bare original copy
if [ -e copy/info/attributes ]; then
     echo "Good, attributes file exists."
else
     echo "Bad! attributes file does not exist in copy."
fi

Re: .git/info/attributes not cloned

[Jeff King]

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.

Can you point out which part of the manual gave the wrong impression (or
better yet, submit a patch making it more clear)?

-Peff

Re: .git/info/attributes not cloned

[Toby Corkindale]

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

Re: .git/info/attributes not cloned

[Jeff King]

On Thu, Mar 27, 2008 at 03:23:27PM +1100, Toby Corkindale wrote:

> 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 -

I vaguely recall some discussion of this in the past, so maybe it isn't
a good idea. But I would think changing git-archive to respect
.gitattributes might be worth doing (presumably the version of
.gitattributes from the tree that is being exported).

> 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.

I think you understand what is going on. A clarification to both pages
would be helpful, I think, just saying "here is why you might use one
over the other."

> Is there a recommended way to make attributes apply to commands run on a  
> remote repository, or is that a different bug?

I'm not sure what you mean here. Very few commands talk to remote
repositories. I had assumed in your git-archive example that you wanted
.gitattributes on the remote repo to affect the tarfile generated by
that repo. But now it sounds like you want to edit a local file to
impact the archive generated remotely. I don't think there is a way to
do that.

-Peff

Re: .git/info/attributes not cloned

[Toby Corkindale]

Jeff King wrote:
> On Thu, Mar 27, 2008 at 03:23:27PM +1100, Toby Corkindale wrote:
> 
>> 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 -
> 
> I vaguely recall some discussion of this in the past, so maybe it isn't
> a good idea. But I would think changing git-archive to respect
> .gitattributes might be worth doing (presumably the version of
> .gitattributes from the tree that is being exported).

Respecting the repo's .gitattributes would feel right. It seems unusual 
(to me) that it bypasses $REMOTE/.gitattributes, but DOES check 
$REMOTE/info/attributes.


>> 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.
> 
> I think you understand what is going on. A clarification to both pages
> would be helpful, I think, just saying "here is why you might use one
> over the other."

Cheers. I've submitted my patch now. I hope I have the doc syntax right.

>> Is there a recommended way to make attributes apply to commands run on a  
>> remote repository, or is that a different bug?
> 
> I'm not sure what you mean here. Very few commands talk to remote
> repositories. I had assumed in your git-archive example that you wanted
> .gitattributes on the remote repo to affect the tarfile generated by
> that repo. But now it sounds like you want to edit a local file to
> impact the archive generated remotely. I don't think there is a way to
> do that.

Ah, no, you were right in your first assumption. I just wanted 
git-archive to apply gitattributes to the resulting tarball.
(I should have phrased that last line as "..apply to commands connecting 
to a remote repo.." and it would make more sense.)

thanks,
Toby

Re: .git/info/attributes not cloned

[Jeff King]

On Thu, Mar 27, 2008 at 03:48:31PM +1100, Toby Corkindale wrote:

>> I vaguely recall some discussion of this in the past, so maybe it isn't
>> a good idea. But I would think changing git-archive to respect
>> .gitattributes might be worth doing (presumably the version of
>> .gitattributes from the tree that is being exported).
>
> Respecting the repo's .gitattributes would feel right. It seems unusual  
> (to me) that it bypasses $REMOTE/.gitattributes, but DOES check  
> $REMOTE/info/attributes.

I agree that it seems like a bug. You might search the list archives for
discussion around the export_subst attribute to see if it was discussed
then or if it is simply an omission.

-Peff

[BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned)

[Toby Corkindale]

Jeff King wrote:
> On Thu, Mar 27, 2008 at 03:48:31PM +1100, Toby Corkindale wrote:
> 
>>> I vaguely recall some discussion of this in the past, so maybe it isn't
>>> a good idea. But I would think changing git-archive to respect
>>> .gitattributes might be worth doing (presumably the version of
>>> .gitattributes from the tree that is being exported).
>> Respecting the repo's .gitattributes would feel right. It seems unusual  
>> (to me) that it bypasses $REMOTE/.gitattributes, but DOES check  
>> $REMOTE/info/attributes.
> 
> I agree that it seems like a bug. You might search the list archives for
> discussion around the export_subst attribute to see if it was discussed
> then or if it is simply an omission.

My searches haven't turned anything up that seems relevant.
I submit that this is a bug, or at least undesirable behaviour:

"git-archive --remote=/some/repo" will ignore /some/repo/.gitattributes, 
but check /some/repo/info/attributes.

I think the problem is in the loop that looks for .gitattributes, which 
seems to do so by taking the current path and iterating down through it?
In the case of remote archives, shouldn't that start by taking the path 
of the repo, not current dir?

Or should it go one step further, and check the .gitattributes for every 
file it extracts? That is the behaviour you get if you run git-archive 
from within a repo, rather than remotely - and don't we want that to be 
consistent with using --remote?

ie. I'm thinking of structures like:
/myModule/testfile.pm
/myModule/subdir/testfile.pm
/myModule/subdir/.gitattributes

if I do "cd /myModule; git-archive HEAD" then shouldn't I get the same 
output as if I did "cd /tmp; git-archive --remote=/myModule HEAD" ?

Re: [BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned)

[Johannes Schindelin]

Hi,

On Fri, 28 Mar 2008, Toby Corkindale wrote:

> I submit that this is a bug, or at least undesirable behaviour:
> 
> "git-archive --remote=/some/repo" will ignore /some/repo/.gitattributes, 
> but check /some/repo/info/attributes.
> 
> I think the problem is in the loop that looks for .gitattributes, which 
> seems to do so by taking the current path and iterating down through it?

The problem is that "git archive --remote" operates on the remote 
repository as if it were bare.  Which in many cases is true.

So I'd submit that this is not the usage .gitattributes is meant for, and 
that you should clone the thing if you want to generate archives heeding 
the .gitattributes.

Ciao,
Dscho

Re: [BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned)

[Jakub Narebski]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Fri, 28 Mar 2008, Toby Corkindale wrote:
> 
> > I submit that this is a bug, or at least undesirable behaviour:
> > 
> > "git-archive --remote=/some/repo" will ignore /some/repo/.gitattributes, 
> > but check /some/repo/info/attributes.
> > 
> > I think the problem is in the loop that looks for .gitattributes, which 
> > seems to do so by taking the current path and iterating down through it?
> 
> The problem is that "git archive --remote" operates on the remote 
> repository as if it were bare.  Which in many cases is true.
> 
> So I'd submit that this is not the usage .gitattributes is meant for, and 
> that you should clone the thing if you want to generate archives heeding 
> the .gitattributes.

This is simply caused by lacking implementation of .gitattributes
(which is quite new feature, so it is somewhat understandable).  

As I see it nothing prevents git to take and use .gitattributes from a
given tree (from a top tree of a given commit)... well, nothing except
the fact that git-check-attr, and probably also API used by attributes
code in builtins, doesn't have place to provide blob to be used as
.gitattributes (or tree to take .gitattributes from).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned)

[Johannes Schindelin]

Hi,

On Fri, 28 Mar 2008, Jakub Narebski wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Fri, 28 Mar 2008, Toby Corkindale wrote:
> > 
> > > I submit that this is a bug, or at least undesirable behaviour:
> > > 
> > > "git-archive --remote=/some/repo" will ignore 
> > > /some/repo/.gitattributes, but check /some/repo/info/attributes.
> > > 
> > > I think the problem is in the loop that looks for .gitattributes, 
> > > which seems to do so by taking the current path and iterating down 
> > > through it?
> > 
> > The problem is that "git archive --remote" operates on the remote 
> > repository as if it were bare.  Which in many cases is true.
> > 
> > So I'd submit that this is not the usage .gitattributes is meant for, 
> > and that you should clone the thing if you want to generate archives 
> > heeding the .gitattributes.
> 
> This is simply caused by lacking implementation of .gitattributes (which 
> is quite new feature, so it is somewhat understandable).
> 
> As I see it nothing prevents git to take and use .gitattributes from a 
> given tree (from a top tree of a given commit)... well, nothing except 
> the fact that git-check-attr, and probably also API used by attributes 
> code in builtins, doesn't have place to provide blob to be used as 
> .gitattributes (or tree to take .gitattributes from).

Of course, you can ask for people to patch it.  Or even provide a patch 
yourself.  Personally, I do not think it is worth it.

Ciao,
Dscho

Re: [BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned)

[Jeff King]

On Fri, Mar 28, 2008 at 01:22:53PM +0100, Johannes Schindelin wrote:

> > "git-archive --remote=/some/repo" will ignore /some/repo/.gitattributes, 
> > but check /some/repo/info/attributes.
> > 
> > I think the problem is in the loop that looks for .gitattributes, which 
> > seems to do so by taking the current path and iterating down through it?
> 
> The problem is that "git archive --remote" operates on the remote 
> repository as if it were bare.  Which in many cases is true.
> 
> So I'd submit that this is not the usage .gitattributes is meant for, and 
> that you should clone the thing if you want to generate archives heeding 
> the .gitattributes.

I don't think it makes sense to operate on or take input from the
working tree of a remote; no other other command does, I don't think. I
had assumed, though, that .gitattributes files _in the tree being
exported_ would be used.

I thought there was some discussion of that a while ago (or possibly of
looking up .gitignore in the same way).

-Peff

Re: [BUG?] git-archive ignores remote .gitattributes

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I thought there was some discussion of that a while ago (or possibly of
> looking up .gitignore in the same way).

Perhaps we would want two distinct modes in dir.c (gitignore stack) and
attr.c (gitattributes stack).  The current code implements the normal mode
that uses the files from the work tree (so that you can modify .gitigore
and expect it to take effect immediately) and fall back to .index (as the
general principle, low-level part of git pretends missing files are
unmodified files when they can).  The new mode, which would be appropriate
for commands such as "archive", would be triggered by first declaring that
the program is going to work on a single tree object, and will cause the
gitignore and gitattributes to be read from that tree (and only that
tree).

Even a longer term clean-up would be (and this is probably a good GSoC
sized project):

 - Unify gitignore and gitattributes stacks;

 - Maintain two or more gitignore/gitattributes stacks in effect at the
   same time.  Things like "git diff-tree $tree1 $tree2", "git diff-index
   --cached $tree", "git diff-index $tree", and "git archive $tree" should
   take attr/ignore from their respective places.

Re: [BUG?] git-archive ignores remote .gitattributes

[Toby Corkindale]

Johannes Schindelin wrote:
> Hi,
> 
> On Fri, 28 Mar 2008, Toby Corkindale wrote:
> 
>> I submit that this is a bug, or at least undesirable behaviour:
>>
>> "git-archive --remote=/some/repo" will ignore /some/repo/.gitattributes, 
>> but check /some/repo/info/attributes.
>>
>> I think the problem is in the loop that looks for .gitattributes, which 
>> seems to do so by taking the current path and iterating down through it?
> 
> The problem is that "git archive --remote" operates on the remote 
> repository as if it were bare.  Which in many cases is true.
> 
> So I'd submit that this is not the usage .gitattributes is meant for, and 
> that you should clone the thing if you want to generate archives heeding 
> the .gitattributes.

If it is not what .gitattributes is for, then what is?
The attributes docs even include specific options for archive mode 
(export-subst), which implies it is exactly meant for archive.

How about $GIT/info/attributes instead? Sadly, that isn't copied during 
clone.

I'd rather not have to clone a potentially large repository just in 
order to make an archive of one specific version. If I was going to have 
to clone it, then I could pass appropriate options to rsync or tar to 
archive instead of calling git-archive.

ie. One could create this:

#!/bin/bash
# Usage: git-archive2  <repo> <treeish>
# note - not actually a real script, don't run this.
REPO=$1
VERSION=$2
git clone $REPO
cd `basename $REPO`
git checkout $VERSION
tar cf - --exclude=.git
cd ..
rm -rf `basename $REPO`


That's silly and shouldn't be required, because git-archive --remote 
exists to perform that work. But it doesn't look at the attributes.

Is there a better way?

thanks,
Toby

-- 
Toby Corkindale
Software developer
w: www.rea-group.com
REA Group refers to realestate.com.au Ltd (ASX:REA)

Warning - This e-mail transmission may contain confidential information.
If you have received this transmission in error, please notify us
immediately on (61 3) 9897 1121 or by reply email to the sender. You
must destroy the e-mail immediately and not use, copy, distribute or
disclose the contents.