From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:06
Alex Riesen [off-list ref] writes:
Imagine a project which started using the attributes at some point of
time. And imagine developers whose repos suddenly start breaking
because of clueless integrator created a filter which does not work
anywere but his system (typical, really) and didn't tell anyone to
update their configuration (whereas .gitattribute files are in working
trees already).
That's one of the reasons why only the filter names are assigned
to paths using gitattributes mechanism and what action to take
when a specific filter name is attached to a path is determined
by the config. Missing filter driver definition in the config
is not an error but makes the filter a no-op passthru.
The content filtering is to massage the content into a shape
that is more convenient for the platform/filesystem/the user to
use. The keyword here is "more convenient" and not "usable"; in
other words, it is "hanging yourself because we gave you a long
rope" if your project tries to do something with the filtering
mechanism to make your project unusable unless the checkout is
done with specific filter in effect. So defaulting to passthru
is meant to fall-back on the plain-old inconvenient checkout,
which is not a bad thing.
How do you suggest to distribute filter configurations, BTW?
The same project description message the participant learn about
the project that says the public repository locations and such,
and perhaps in-tree READ.ME file.
The earlier example I gave would fit this pattern rather well.
If somebody (me) cannot deal with UTF-8 encoded Japanese text
very well, that user personally can mark such a file in
$GIT_DIR/info/attributes as 'filter=utf8-japanese-text' and
define the iconv based filtering driver in $GIT_DIR/config in
the repository that he (me) uses for editing.
In addition, I would most likely have another repository that
does not have the filtering driver defined, and that would be
where I would run the build tools for documentation part, since
the project documentation is supposed to be in UTF-8.
This is a "purely personal" setting that does not have to be
known to the outside world. But the filter=utf8-japanese-text
attribute could be shared in-tree if the project has more then
one person with difficulty dealing with UTF-8 encoded Japanese
text. I may personally edit the file after having iconv convert
to EUC-JP and convert it back to UTF-8 when checking in, but the
other person may use local encoding different from EUC-JP for
editing. In such a case, only the definition in our config
files are different, and in-tree Documentation/.gitattributes
file would have
git-lost-found.txt filter=utf8-japanese-text
which is distributed project-wide.
Repositories used by people who do not have trouble handling
UTF-8 encoded Japanese text would not have any filtering driver
defined for utf8-japanese-text in their $GIT_DIR/config, and
their checkout would be in UTF-8, because of this passthru
behaviour.
How about checkout performance impact?
Measurement would be interesting; I haven't done it, and that is
one of the smaller reasons I am not particularly keen on pushing
the 'filter' attribute. Hawk-eyed people might have noticed
that I swapped the order of the series in 'pu' to have 'ident'
first and then 'filter'.
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:06
On 4/23/07, Junio C Hamano [off-list ref] wrote:
Alex Riesen [off-list ref] writes:
quoted
Imagine a project which started using the attributes at some point of
time. And imagine developers whose repos suddenly start breaking
because of clueless integrator created a filter which does not work
anywere but his system (typical, really) and didn't tell anyone to
update their configuration (whereas .gitattribute files are in working
trees already).
That's one of the reasons why only the filter names are assigned
to paths using gitattributes mechanism and what action to take
when a specific filter name is attached to a path is determined
by the config. Missing filter driver definition in the config
is not an error but makes the filter a no-op passthru.
Fragile. What if content is useless without filter? How does
the user know about the fact so he can work the problem
around?
What if you have multiple filters matching the same path?
(does not seem to be possible. Someone will ask you why)
The content filtering is to massage the content into a shape
that is more convenient for the platform/filesystem/the user to
use. The keyword here is "more convenient" and not "usable"; in
how can "not usable" be "more convenient"?
quoted
How do you suggest to distribute filter configurations, BTW?
The same project description message the participant learn about
the project that says the public repository locations and such,
and perhaps in-tree READ.ME file.
But there seem to be no way to notice that the READ.ME should
be reread by project participants downstream.
The earlier example I gave would fit this pattern rather well.
If somebody (me) cannot deal with UTF-8 encoded Japanese text
very well, that user personally can mark such a file in
$GIT_DIR/info/attributes as 'filter=utf8-japanese-text' and
define the iconv based filtering driver in $GIT_DIR/config in
the repository that he (me) uses for editing.
which will be a PITA to setup in each and every clone of the
repository, unless it is cloned with the repo.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:06
Hi,
On Tue, 24 Apr 2007, Alex Riesen wrote:
On 4/23/07, Junio C Hamano [off-list ref] wrote:
quoted
The earlier example I gave would fit this pattern rather well.
If somebody (me) cannot deal with UTF-8 encoded Japanese text
very well, that user personally can mark such a file in
$GIT_DIR/info/attributes as 'filter=utf8-japanese-text' and
define the iconv based filtering driver in $GIT_DIR/config in
the repository that he (me) uses for editing.
which will be a PITA to setup in each and every clone of the
repository, unless it is cloned with the repo.
Not if you do it with templates. If it is such a special case that you
absolutely _need_ filters, and cannot use it without filters, it is
probably in a very small group. And there, you just setup the templates,
and voila: you have your filters without much ado.
Ciao,
Dscho
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:06
On 4/24/07, Johannes Schindelin [off-list ref] wrote:
quoted
which will be a PITA to setup in each and every clone of the
repository, unless it is cloned with the repo.
Not if you do it with templates. If it is such a special case that you
absolutely _need_ filters, and cannot use it without filters, it is
probably in a very small group. And there, you just setup the templates,
and voila: you have your filters without much ado.
It can be a very big group. Than, even if it is the only group in the world,
it can complain loud and long enough to become a major annoyance.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:06
Hi,
On Tue, 24 Apr 2007, Alex Riesen wrote:
On 4/24/07, Johannes Schindelin [off-list ref] wrote:
quoted
quoted
which will be a PITA to setup in each and every clone of the
repository, unless it is cloned with the repo.
Not if you do it with templates. If it is such a special case that you
absolutely _need_ filters, and cannot use it without filters, it is
probably in a very small group. And there, you just setup the
templates, and voila: you have your filters without much ado.
It can be a very big group. Than, even if it is the only group in the
world, it can complain loud and long enough to become a major annoyance.
Yes, they can.
And if we can prove that it would have been cleaner and better and more
stable to do the same without attributes, they will look like a big group
of total morons.
Ciao,
Dscho
From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:06
"Alex Riesen" [off-list ref] writes:
On 4/23/07, Junio C Hamano [off-list ref] wrote:
quoted
...
That's one of the reasons why only the filter names are assigned
to paths using gitattributes mechanism and what action to take
when a specific filter name is attached to a path is determined
by the config. Missing filter driver definition in the config
is not an error but makes the filter a no-op passthru.
Fragile. What if content is useless without filter?
In that case, the project screwed itself and it is not our
problem anymore ;-).
quoted
The content filtering is to massage the content into a shape
that is more convenient for the platform/filesystem/the user to
use. The keyword here is "more convenient" and not "usable"; in
how can "not usable" be "more convenient"?
I think I worded it incorrectly to be misunderstood, but I
couldn't word them better then, I do not know I can word them
better now.
Something could be 1. unusable, or 2. usable. Among usable
shapes, there are 2-a. inconvenient but usable and 2-b. very
convenient to use.
What I tried to say was that if you use filtering mechanism to
massage contents that is unusable into usable (i.e. crossing
from 1 to 2), you are already misusing the mechanism (but we do
not prevent you because we are only "giving you a long rope").
The filter is meant to be used to cross from 2-a to 2-b.
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:06
On 4/24/07, Junio C Hamano [off-list ref] wrote:
quoted
quoted
The content filtering is to massage the content into a shape
that is more convenient for the platform/filesystem/the user to
use. The keyword here is "more convenient" and not "usable"; in
how can "not usable" be "more convenient"?
I think I worded it incorrectly to be misunderstood, but I
couldn't word them better then, I do not know I can word them
better now.
You don't have to. I just can't force myself to believe it can be
made useful. I'll shut up for now, and wait until I or someone else
proves the code has negligible negative impact on the normal
usage scenarios.