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

From: Alex Riesen <raa.lkml@gmail.com>
Date: Apr 24, 2007, 15:58 UTC
Message-ID: <81b0412b0704240858w6121430fj624582539f14ceee@mail.gmail.com>
In-Reply-To: <7v4pn6ep41.fsf@assigned-by-dhcp.cox.net>

On 4/23/07, Junio C Hamano <junkio@cox.net> wrote:

Show 14 quoted lines

> 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.

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"?

Show 5 quoted lines

> > 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.

Show 6 quoted lines

> 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.