On Thu, Oct 11, 2012 at 2:04 PM, Michael Haggerty wrote:
> Maybe I'm being too much of a purist, but I don't think that git should
> retroactively reinterpret history on its own initiative in a way that
> might not be correct (e.g., maybe your encoding changed from ASCII to
> Shift-JIS sometime in
On 10/11/2012 07:55 AM, Johannes Sixt wrote:
> Am 10/10/2012 21:44, schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>
>>> Is there already an established definition which the "correct"
>>> .gitattributes are?
>>
>> No, and it is deliberately kept vague while waiting for us to come
>> up with a c
Am 10/10/2012 21:44, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Is there already an established definition which the "correct"
>> .gitattributes are?
>
> No, and it is deliberately kept vague while waiting for us to come
> up with a clear definition of what is "correct".
...
> Very oft
Johannes Sixt writes:
> Is there already an established definition which the "correct"
> .gitattributes are? IIRC, everywhere else we are looking at the
> .gitattributes in the worktree, regardless of whether the object at the
> path in question is in the worktree, the index, or in an old commit.
On Wed, Oct 10, 2012 at 7:43 PM, Johannes Sixt wrote:
> Am 10/10/2012 14:32, schrieb Nguyen Thai Ngoc Duy:
>> git-archive has --worktree-attributes to specify where attributes come
>> from. Sparse checkout can choose to read index version first then
>> worktree's or the other way around. All norma
Am 10/10/2012 14:32, schrieb Nguyen Thai Ngoc Duy:
> git-archive has --worktree-attributes to specify where attributes come
> from. Sparse checkout can choose to read index version first then
> worktree's or the other way around. All normal operations read
> worktree version, if not found index ver
On Wed, Oct 10, 2012 at 7:12 PM, Johannes Sixt wrote:
> Is there already an established definition which the "correct"
> .gitattributes are?
If I ask to grep the index then to me it should read only the index.
Although other people can counter that they may want different
attributes than the one
Am 10/10/2012 14:03, schrieb Nguyen Thai Ngoc Duy:
> On Wed, Oct 10, 2012 at 6:51 PM, Johannes Sixt wrote:
>> Thanks for working on this issue!
>>
>> Am 10/10/2012 13:34, schrieb Nguyễn Thái Ngọc Duy:
>>> + linkgit:gitattributes[5]). Note that .gitattributes are only
>>> + support for sear
On Wed, Oct 10, 2012 at 6:51 PM, Johannes Sixt wrote:
> Thanks for working on this issue!
>
> Am 10/10/2012 13:34, schrieb Nguyễn Thái Ngọc Duy:
>> + linkgit:gitattributes[5]). Note that .gitattributes are only
>> + support for searching files in working directory.
>
> Does this mean it do
Thanks for working on this issue!
Am 10/10/2012 13:34, schrieb Nguyễn Thái Ngọc Duy:
> + linkgit:gitattributes[5]). Note that .gitattributes are only
> + support for searching files in working directory.
Does this mean it does not work for 'git grep --cached'? That would be a
real loss.
grep searches for .gitattributes using "name" field in struct
grep_source but that field is not real on-disk path name. For example,
"grep pattern rev" fills the field with "rev:path", which is
non-existent usually until somebody exploits it to drive git away.
attr does not support looking up .git
11 matches
Mail list logo
