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

[Martin Geisler]

Jason Harris <jason at jasonfharris.com> writes:

> On Apr 18, 2011, at 1:35 PM, Martin Geisler wrote:
>
>> Jason Harris <jason at jasonfharris.com> writes:
>> 
>> 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.
>
> Sure technically you are totally correct, but does the above
> replacement seem like an encode, or a decode operation to you?

You 'encode' files when you store them in the repository and 'decode'
them when you write to the working copy. I guess it make some sense to
apply the decode filter when you read data from the original repository
and apply the encode filter when you write data to the new repository.

You can specify your filter as either an encode or decode filter, both
will work assuming that they are both applied... So maybe it's stupid to
overload this mechanism here after all.

A better option would be to let the user specify a file with patterns
and corresponding filters:

  hg convert --filters = myfilters.txt

where myfilters.txt contains

  **.c = sed 's|foo|bar'

or something like that.

> Of course changing line endings, or tab conversion seems like an
> encoding / decoding operation. But the above search are replace
> operations are not semantically a encode / decode operation in my
> mind... It would just seem a little odd for a sequence of replacements
> like:
>
>    foo -> bar
>    baz -> quux
>  
> to be thought of as an encoding...

Yeah, it's of course a strange "encoding". It's really a filter and that
is what the encode/decode setting allow you to configure, nothing more.

> Yep. The one neat thing is git-filter-branch can run a filter over the
> entire tree at the same time [...]

I'm not sure where you read that? I cannot find anything about this in
the 'git help filter-branch' text.

> In any case. I can make the minor changes to make this work with:
>
>>> contentsfilter -> filter
>>> using stdin and stdout instead of passing the data via the command line.
>
> Or I can happily leave it to others to hook this up through encode /
> decode if anyone is interested in doing this?

I don't think anybody will do it for you -- otherwise it would have been
done a long time ago :)

-- 
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/5ac12617/attachment.pgp>