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

[Matt Harbison]

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.

>> @@ -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.)

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, and tack {pointer} and {oid} on to each  
entry somehow?