Re: [PATCH] optionally disable gitattributes

["Torsten Bögershausen" <tboegi@web.de>]

On 27.01.16 12:59, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
> 
>> If committed files are not normalized, adding gitattributes has the
>> side effect that such files are shown as modified, even though they
>> were not actually modified by the user, and the work tree matches
>> the committed file. This is because with gitattributes, the file is
>> modified on the fly when git reads it from disk, before it compares
>> with the index contents.
>>
>> This is desirable in most situations, because it makes the user
>> aware that files should be normalized. However, it can become an
>> issue for automation. Since Git considers the work tree to be
>> dirty, some operations such as git rebase or git cherry-pick refuse
>> to operate. Those commands offer no flag to force overwrite work
>> tree changes. The only options are to commit the changes, or to
>> remove gitattributes, but that changes the repository state, which
>> may be undesirable in a scripted context.
It feels like a workaround for something that could be fixable, or is already ongoing.
Before going into more details,
could you tell us which attributes you are typically using (when having this problems) ?
Is it
* text=auto
or
*.sh text 
or something else?


>>
>> Introduce an environment variable GIT_ATTRIBUTES_DISABLED, which if
>> set makes Git ignore any gitattributes.
>>
>> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
>> ---
> 
> Is the problem you are trying to solve related to the issue we
> discussed recently in a nearby thread?
It seems that I missed the thread ?
> 
> That is, even after "reset --hard", if the result of converting the
> contents in the index to the working tree representation and then
> converting that result back to the normalized representation does
> not match what is in the index, Git would sometimes say that the
> working tree contents differ from the index?
> 
> I think the change in this patch has some uses, and I think the
> issue we discussed recently in a nearby thread indeed is a problem,
> but I do not think there is an impedance mismatch beween the two, so
> I'd like to first make sure you are trying to solve the problem I
> think you are trying to solve.