Re: What's cooking in git.git (topics)

[Junio C Hamano <junkio@cox.net>]

Alex Riesen <raa.lkml@gmail.com> 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'.