[PATCH 0 of 1] Interest for convert option --contentsfilter?

[Martin Geisler]

Jason Harris <jason at jasonfharris.com> writes:

> On Apr 18, 2011, at 12:00 PM, Martin Geisler wrote:
>
>> The filtering on filenames makes me think of our encode/decode
>> filters... could we instead use that API and infrastructure? So
>> instead of a new option to convert we let convert read/write data
>> through the normal encode/decode filters. That already allows for
>> calling both shell scripts and Python functions.
>
> Maybe, but the point is that it's just one type of filtering.
>
> I might have another filter which is
>
> newContents = re.sub(r"(\W)BrowserView(\W)", r"\1FileView\2", originalContents)
> newContents = re.sub(r"(\W)inspectorBWSplitView(\W)", r"\1inspectorSplitView\2", newContents)
> newContents = re.sub(r"(\W)reasonForInvalIdityOfSelectedEntries(\W)", r"\reasonForInvalidityOfSelectedEntries\2", newContents)
>
> or something like that.. ie a series of global replacements on the
> contents to correct annoying mistakes.
>
> Or I could restrict such changes to just certain functions since the
> hash is passed in. In fact although its not passed in now one could
> imagine passing in as well the rev number and only doing a
> transformation for a certain range of changesets.
>
> Thus I don't see this is exactly the same as a normal encode / decode
> filter. I guess though one common use for it will be to fix eol,
> everywhere and consistently throughout the repo.

The encode/decode filters get the original file content on stdin and
have to produce the new file content on stdout. Such a filter can do the
above subsitutions just fine. The only part missing is information about
the current filename and the current changeset hash -- we could provide
them to the filter via environment variables in the same fashion as how
we provide such information to hooks.

I don't really like the encode/decode filters that much, but now that we
have them, then using them might make sense.

> Thus would this be accepted / included with name change:
>
>  contentsfilter -> filter
>  using stdin and stdout instead of passing the data via the command line.
>
> I didn't mention it but some people might already know that git has
> such an option git-filter-branch, and this allows Mercurial to do the
> same thing...

Yeah, I would like to see Mercurial provide the same filtering
capabilities in a clean way.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110418/0e6b7e2d/attachment.pgp>