.git/info/attributes not cloned

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

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

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 -

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

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

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

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

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

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

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

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

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

Hi,

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

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

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.

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

Hi,

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

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.