From: Junio C Hamano <gitster@pobox•com>
To: Clemens Buchacher <drizzd@aon•at>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] optionally disable gitattributes
Date: Wed, 27 Jan 2016 03:59:21 -0800 [thread overview]
Message-ID: <xmqqy4bb8c86.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160127095021.GA25281@ecki.hitronhub.home> (Clemens Buchacher's message of "Wed, 27 Jan 2016 10:50:21 +0100")
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.
>
> 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?
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.
next prev parent reply other threads:[~2016-01-27 11:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 9:50 [PATCH] optionally disable gitattributes Clemens Buchacher
2016-01-27 11:59 ` Junio C Hamano [this message]
2016-01-27 15:04 ` Torsten Bögershausen
2016-01-27 15:25 ` Clemens Buchacher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy4bb8c86.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=drizzd@aon$(echo .)at \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox