[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