Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

From: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Date: Jun 25, 2010, 19:43 UTC
Message-ID: <CFE3DCC1-E80A-4EF3-964B-E791D3224F06@gmail.com>
In-Reply-To: <7vtyosnj23.fsf@alter.siamese.dyndns.org>

On 25. juni 2010, at 00.48, Junio C Hamano wrote:

Show 10 quoted lines

> Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> writes:
> 
>> Hm.  Isn't that already a requirement?  If a clean filter doesn't clean
>> to something normalized, simply touching a file could result in spurious
>> differences (much like pre-safe-autocrlf autocrlf).  I could well be
>> missing something here, though.
> 
> A natural expectation would be that g2w-then-w2g is an identity function,
> I think.  But the "feature" under discussion in this thread depends on
> that g2w-then-w2g is _not_ a noop (otherwise it wouldn't do us any good).

Well, it assumes that g2w does not smudge already smudged data (or that w2g can clean up after double smudging), but when the assumption fails you end up with the same merge conflict you would get without this series.  Is it important that _all_ filters support merging?

Show 5 quoted lines

> IOW, we are suggesting authors of clean/smudge to make their g2w-then-w2g
> perform more than just a round-trip but actively _clean things up_, aren't
> we?  I don't think we have documented that suggestion, and I actually
> think we might even have said that g2w-then-w2g should be a no-op
> somewhere in the documentation.

I think it's worth documenting that a well-written ("normalizing", as Finn Arne said) filter allows automatic merging of filtered and unfiltered data.  I'll see what I can come up with.

-- 
Eyvind