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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> Eyvind Bernhardsen <eyvind.bernhardsen@xxxxxxxxx> 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?

> 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]