From: Junio C Hamano <gitster@pobox.com>
To: Frank Ammeter <git@ammeter.ch>
Cc: "Brandon McCaig" <bamccaig@gmail.com>,
"Torsten Bögershausen" <tboegi@web.de>,
git@vger.kernel.org
Subject: Re: wrong handling of text git attribute leading to files incorrectly reported as modified
Date: Wed, 16 Apr 2014 09:50:19 -0700 [thread overview]
Message-ID: <xmqqob01i5h0.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <B3DF4E4A-F740-4588-AFD5-74D99E5299F5@ammeter.ch> (Frank Ammeter's message of "Wed, 16 Apr 2014 13:49:02 +0200")
Frank Ammeter <git@ammeter.ch> writes:
> Am 15.04.2014 um 23:23 schrieb Junio C Hamano <gitster@pobox.com>:
>
>> Brandon McCaig <bamccaig@gmail.com> writes:
>>
>>> That is for your benefit, and for easily sharing that configuration
>>> with collaborators. Git only cares that the file exists in your
>>> working tree at run-time.
>>
>> It is a lot more than "for sharing". If you made .gitignore only
>> effective after it gets committed, you cannot test your updated
>> version of .gitignore is correct before committing the change.
>
> Ok, I can follow that logic for .gitignore, but I was talking about .gitattributes...
They are conceptually the same thing, so if you can follow the logic
for .gitignore, you already can follow the logic for .gitattributes.
The only two readons we have a separate .gitignore are because other
SCMs had a similar mechanism, and because it came before attributes.
If we didn't have these two constraints, it would have made a lot
more sense to express "this path is to be ignored" by setting
"ignored" attribute.
next prev parent reply other threads:[~2014-04-16 16:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-11 20:20 wrong handling of text git attribute leading to files incorrectly reported as modified Frank Ammeter
2014-04-11 20:38 ` Torsten Bögershausen
2014-04-12 11:29 ` Frank Ammeter
2014-04-15 20:12 ` Brandon McCaig
2014-04-15 21:23 ` Junio C Hamano
2014-04-16 11:49 ` Frank Ammeter
2014-04-16 16:50 ` Junio C Hamano [this message]
2014-04-16 17:03 ` Holger Hellmuth
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=xmqqob01i5h0.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=bamccaig@gmail.com \
--cc=git@ammeter.ch \
--cc=git@vger.kernel.org \
--cc=tboegi@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.