# smudge/clean filters and SHA1 hashes 3 messages from 2014-05-02 to 2014-05-02. Participants: Leo Razoumov, Shawn Pearce, Junio C Hamano. Thread: https://gitlist.dev/t/36568 ## Leo Razoumov, 2014-05-02 21:05 Subject: smudge/clean filters and SHA1 hashes Message-ID: URL: https://gitlist.dev/e/CADsUFkQLtUDpoiSqj-UYeyz1a-WZPh9vN%2BRW4ti8ut%3D22QwL4g%40mail.gmail.com ``` Hi All, surprisingly, searching this list and by way of Google I cannot find an answer to a simple question: In presence of smudge/clean filters which SHA1 hash (clean content or smudged content) gets stored in the repository? Thanks, --Leo-- P.S. Very similar question [1] was posted here in 2012 but went unanswered. [1] http://git.661346.n2.nabble.com/workflow-clarification-sha1-merge-patch-diff-ws-smudge-clean-td7561818.html ``` ## Shawn Pearce, 2014-05-02 21:07 Subject: Re: smudge/clean filters and SHA1 hashes Message-ID: URL: https://gitlist.dev/e/CAJo%3DhJurLa9rdHNHS01uW3FEd_yNPzdFE8X4xaOWCFCnzF7MUg%40mail.gmail.com In-Reply-To: ``` On Fri, May 2, 2014 at 2:05 PM, Leo Razoumov wrote: > surprisingly, searching this list and by way of Google > I cannot find an answer to a simple question: > > In presence of smudge/clean filters which SHA1 hash > (clean content or smudged content) gets stored in the repository? The clean version is used to obtain the SHA-1. ``` ## Junio C Hamano, 2014-05-02 22:02 Subject: Re: smudge/clean filters and SHA1 hashes Message-ID: URL: https://gitlist.dev/e/xmqqeh0balgd.fsf%40gitster.dls.corp.google.com In-Reply-To: ``` Leo Razoumov writes: > In presence of smudge/clean filters which SHA1 hash > (clean content or smudged content) gets stored in the repository? You are cleaning cruft in the contents before the contents are hashed to compute the object name. The point is to keep clean objects in the object database, protected from dirty reality in the working tree (which you instanciate by applying the smudge filter to dirty the clean object in the ideal world). The crlf conversion works exactly the same way. For portability, you keep a version terminated with LF in the object database and that is what is hashed to compute the blob object name, but we export with CRLF line endings for a working tree that wants files whose lines are terminated that way. ```