[PATCH 4 of 4] hgweb: remove now unnecessary explicit header() and footer()

Alexander Plavin alexander at plav.in
Fri Aug 9 07:46:44 CDT 2013



09.08.2013, 16:30, "Martin Geisler" <martin at geisler.net>:
> Alexander Plavin <alexander at plav.in> writes:
>
>>  09.08.2013, 15:30, "Martin Geisler" <martin at geisler.net>:
>>>  Alexander Plavin <alexander at plav.in> writes:
>>>>   09.08.2013, 11:07, "Martin Geisler" <martin at geisler.net>:
>>>>>   Alexander Plavin <alexander at plav.in> writes:
>>>>>>    # HG changeset patch
>>>>>>    # User Alexander Plavin <alexander at plav.in>
>>>>>>    # Date 1374621626 -14400
>>>>>>    #      Wed Jul 24 03:20:26 2013 +0400
>>>>>>    # Node ID 11ac049356d4894642313803d9edc1ff2e9d2788
>>>>>>    # Parent  1fe956e499f2996d4b63ae04c2ec99fe39e89302
>>>>>>    hgweb: remove now unnecessary explicit header() and footer()
>>>>>   I think it could be nice if you added a tiny bit of context: when and
>>>>>   why did this become unnecessary (which changeset does "now" refer to)?
>>>>>
>>>>>   My first guess would be that the immediate parent (patch 3) makes the
>>>>>   functions unnecessary, but it doesn't look like it to me. So my second
>>>>>   guess is that "now" refers to patch 2. That suggests that the patches
>>>>>   could be reordered by swapping 3 and 4.
>>>>   You are right that this depends on patch 2 only, but why reorder?
>>>>   Third patch also depends on that, so it could cause the same question
>>>>   as well if they were reordered :)
>>>  Aha... :-) I somehow thought that moving a string as you do in patch 3
>>>  was already supported. Maybe you could explain more clearly in patch 2
>>>  that it allows you to use the map file as a key-value store for plain
>>>  strings as well (if that is actually what patch 2 does).
>>  I've thought a bit about better commit message for 2nd patch now, but
>>  couldn't improve what's already there :) Quote from that commit:
>>  "allows adding arbitrarily-named entries to a template map file, and
>>  then referencing them" - this includes plain strings too. Any
>>  suggestion?
>
> I guess the problem is that I don't know what an "arbitrarily-named
> entry" is :)
>
> It's been a long time since I looked at the map file format in detail,
> but I were asked to describe it, I would describe the format as a bunch of
>
>   key = value
>
> lines where "value" can reference other keys. If I would have to name
> one of sides "entry", I would have described the lines this:
>
>   entry = expansion
>
> I now get the impression that you would describe the format as:
>
>   reference = entry
>
> or something similar.

Yes, the format is 'key = entry', where by entry I mean entry content, expansion in your terms. And now (without the 2nd patch from this series) you can define entries with only hard-coded keys, not arbitrary.

>
> --
> Martin Geisler


More information about the Mercurial-devel mailing list