Details

This redefines the {file_adds}, {file_dels}, {file_mods} template
keywords by getting the lists from the recently introduced context
methods instead of getting them from status compared to p1. As
mentioned before, these are better defined on merge commits. The total
number of files from the three lists now always add up to the number
of files in {files}.

This redefines the template keywords by getting the lists from the
recently introduced context methods instead of getting them from
status compared to p1. A mentioned before, these are better defined on
merge commits. The total number of files from the three lists now
always add up to the number of files in {files}.

So this is a BC, and makes log -T status output differ fromstatus --change REV. Just pointed out.

I'm 0 on this change. I feel the new definition makes more sense, but
the old one seems also okay and is simpler.

> This redefines the template keywords by getting the lists from the
> recently introduced context methods instead of getting them from
> status compared to p1. A mentioned before, these are better defined

on

> merge commits. The total number of files from the three lists now
> always add up to the number of files in {files}.
So this is a BC, and makes `log -T status` output differ from
`status --change REV`. Just pointed out.

Depends on whether you consider the bug valid, right? We don't mark bug
fixes as BC. But I agree with still listing this in the "backwards
compatibility" section of the release notes.

I'm 0 on this change. I feel the new definition makes more sense, but
the old one seems also okay and is simpler.

I agree, but it also seems unlikely that anyone would depend on the old
behavior.

BTW, and this is also related to your comments on the previous patch,{files} is probably already inconsistent in the working copy when merging
and after committing the merge. I don't think we should change that. But I
think it means that the number of modified, added, and removed files add up
to the files in that keyword in the working copy, even though they're all
compared to just p1. It's just another example of the working copy status
being weird before committing a merge.

martinvonz retitled this revision from templatekw: get file_{adds,mods,dels} directly from context (issue4292) to templatekw: make {file_*} compare to both merge parents (issue4292).Thu, May 16, 4:53 PM