get language from .gitattributes file

[a1012112796]

rules:
linguist-language= attribute to an lang
linguist-vendored attribute to vendor or un-vendor path

ref:
https://stackoverflow.com/questions/40659265/using-gitattributes-for-linguist-examples

fixes #14786

[noerw]

The docs need to explain this feature & its syntax, similar to https://github.com/github/linguist/blob/master/docs/overrides.md

fixes #14786

[zeripath]

Why aren't you using check-attr and already written function that uses it?

[zeripath]

NAME
       git-check-attr - Display gitattributes information

SYNOPSIS
       git check-attr [-a | --all | <attr>...] [--] <pathname>...
       git check-attr --stdin [-z] [-a | --all | <attr>...]

DESCRIPTION
       For every pathname, this command will list if each attribute is unspecified, set, or unset as a
       gitattribute on that pathname.

// CheckAttributeOpts represents the possible options to CheckAttribute
type CheckAttributeOpts struct {
	CachedOnly    bool
	AllAttributes bool
	Attributes    []string
	Filenames     []string
}

func (repo *Repository) CheckAttribute(opts CheckAttributeOpts) (map[string]map[string]string, error) {
    ...
    return name2attribute2info, nil
}

The signature of this function isn't great but it could easily be improved.

[a1012112796]

Why aren't you using check-attr and already written function that uses it?

I know it. But if use this cmd, should create tmp repo(this cmd can't be used in a bare repo, example:

), which is a more big work. so I think just analys this file content directly is more simple.

[lunny]

Why aren't you using check-attr and already written function that uses it?

I know it. But if use this cmd, should create tmp repo(this cmd can't be used in a bare repo, example:

), which is a more big work. so I think just analys this file content directly is more simple.

So the above function CheckAttribute does not work?

[zeripath]

Ah... Ok. There's a way to make it work in bare repos - you read-tree into a (temporary) index file and then use that index file with --cached. (Which reminds me as to why I hadn't done this already.)

I guess we need to decide which is better - potentially parsing the file incorrectly ourselves versus the complexity of the above operation. Certainly if we're planning on calling gitattribites a lot we don't want to be writing and throwing away index files all the time.

I'll have to take a look at the .gitattribites format - iirc it's kinda complex with lots of globbing. We'll have to be cautious with reading this.

[a1012112796]

Ah... Ok. There's a way to make it work in bare repos - you read-tree into a (temporary) index file and then use that index file with --cached. (Which reminds me as to why I hadn't done this already.)

I see, but maybe create index file in the bare repo is a dangerous work, becaue maybe will be double write ...
so maybe the most simple way is create tmp repo, and do check-attr in it...

[zeripath]

No, you can create an index file anywhere and make git use it with the environment variable GIT_INDEX_FILE. Creating a temp repo is very slow.

[zeripath]

Ok GIT_INDEX_FILE=$TMP_INDEX_FILE git restore --staged $DEFAULT_BRANCH -- .gitattributes can be used to set a single blob as an index then GIT_INDEX_FILE=$TMP_INDEX_FILE git check_attr --cached could be used to query it.

The reason for the restore rather than read-tree is that read-tree has to read the entire tree and subtrees so restore should be quicker.

It would be great if we could figure out a way to tell check-attr to just use a piped in .gitattributes but I don't think that's possible.

[a1012112796]

Ok GIT_INDEX_FILE=$TMP_INDEX_FILE git restore --staged $DEFAULT_BRANCH -- .gitattributes can be used to set a single blob as an index then GIT_INDEX_FILE=$TMP_INDEX_FILE git check_attr --cached could be used to query it.

The reason for the restore rather than read-tree is that read-tree has to read the entire tree and subtrees so restore should be quicker.

It would be great if we could figure out a way to tell check-attr to just use a piped in .gitattributes but I don't think that's possible.

I see, but sadly can't use restore cmd in here. firstly, the restore can't be used in bare repo (It has NEED_WORK_TREE label) . secondly, it fact. .gitattributes can be added in subtree also.
now I has changed to use read-tree and check-attr. But I wonder whether it's a better solution than previous, because the check-attr can check only one file in one time ....

[zeripath]

OK Now I understand what this is doing - I think we're gonna need a pipe which goes to write to an open

git check-attr --stdin ...

and then read and parse the line produced per path.

Otherwise you're going to get n calls to git check-attr per repository.

[a1012112796]

Close via #16773