From: Junio C Hamano Date: Thu, 24 Jun 2010 22:48:36 GMT Subject: Re: What's cooking in git.git (Jun 2010, #04; Wed, 23) Message-ID: <7vtyosnj23.fsf@alter.siamese.dyndns.org> In-Reply-To: <40D1B374-E80A-4BA2-B3A2-142E8256C23E@gmail.com> Eyvind Bernhardsen writes: > On 24. juni 2010, at 22.21, Junio C Hamano wrote: > >> Finn Arne Gangstad writes: >> >>> If .gitattributes is different on the different sides, or if you >>> enable autocrlf, the current repo contents may change after >>> git-to-worktree and worktree-to-git again. >> >> IOW, g2w-then-w2g may not be an identity function. >> >> If we were to encourage use of this codepath to wider audiences, we may >> need to have a document for people who write smudge/clean filters. In >> order for the result to be stable, applying g2w-then-w2g once again on top >> of the result of running g2w-then-w2g on anything should be no-op, no? > > 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). 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.