[PATCH V2] lfs: add the '{lfsattrs}' template keyword to '{lfs_files}'

Matt Harbison mharbison72 at gmail.com
Sat Jan 20 03:06:59 EST 2018


On Sat, 20 Jan 2018 02:38:11 -0500, Yuya Nishihara <yuya at tcha.org> wrote:

> On Sat, 20 Jan 2018 01:34:49 -0500, Matt Harbison wrote:
>> On Fri, 19 Jan 2018 07:21:30 -0500, Yuya Nishihara <yuya at tcha.org>  
>> wrote:
>>
>> > On Fri, 19 Jan 2018 00:05:42 -0500, Matt Harbison wrote:
>> >> # HG changeset patch
>> >> # User Matt Harbison <matt_harbison at yahoo.com>
>> >> # Date 1515967224 18000
>> >> #      Sun Jan 14 17:00:24 2018 -0500
>> >> # Node ID fccf09e44f5124abf18ae898fab553ea6d91e951
>> >> # Parent  45b678bf3a787085d56fad5bee494e0c160aa120
>> >> lfs: add the '{lfsattrs}' template keyword to '{lfs_files}'
>> >
>> > Queued updated version, thanks.
>> >
>> >> I liked {pointer} better, but couldn't make it work with the
>> >> singular/plural
>> >> forms.
>> >
>> > I think {pointer} is okay here since its singular form is ({key},
>> > {value}).
>>
>> OK, I'll rename after the freeze.
>
> I think it's okay to rename that before cutting rc. Can you send a patch?

Done.

>> >> @@ -303,6 +304,8 @@
>> >>      # when writing a bundle via "hg bundle" command, upload related
>> >> LFS blobs
>> >>      wrapfunction(bundle2, 'writenewbundle', wrapper.writenewbundle)
>> >>
>> >> +    templatekw.defaulttempl['lfsattr'] = '{key}={value}'
>> >
>> > This isn't needed. Dropped.
>>
>> Does that mean the envvar entry isn't needed?  Somehow, the output I was
>> getting was all of the keys run together, and that made me think of
>> envvar.  (Unfortunately, I didn't commit the code, so I can't go back to
>> see what exactly was wrong.)
>
> showdict|list() requires defaulttempl entry to support old-style list
> templates. hybriddict|list() doesn't.
>
>> I wonder if this strategy is wrong in general.  Regular templates have
>> {files}, {file_adds}, {file_copies}, {file_copies_switch}, {file_dels},
>> {file_mods}, and {files(PATTERN)}.  It would be silly to copy all of
>> that.  But filters seem only text oriented.  Could a hypothetical
>> {lfs_files()}
>> filter all of these to lfs only,
>
> A unary template function can acts as a filter.

I saw the comment in there suggesting that, but in practice it looks like  
pretty much everything is text, plus some optional control parameters.   
Minimally, this would need a context too.

>> and tack {pointer} and {oid} on to each
>> entry somehow?
>
> Alternatively, we could add pointer and oid to files entry only when it
> is backed by lfs.

I like this idea better, because then it's always available, not just when  
run through the filter/function.  But short of hard coding it in core,  
what else can be done?  Wrap templatekw._showlist(), look for file related  
name arguments and modify the mapping parameter?  Would a {...|lfs} filter  
be OK in addition to this for readability?


More information about the Mercurial-devel mailing list