[PATCH 12 of 12] templater: add a method to list labels in a namespace

Sean Farley sean.michael.farley at gmail.com
Thu Aug 21 13:30:24 CDT 2014


Angel Ezquerra writes:

> On Tue, Aug 19, 2014 at 5:21 PM, Sean Farley
> <sean.michael.farley at gmail.com> wrote:
>>
>> Augie Fackler writes:
>>
>>> On Mon, Aug 18, 2014 at 04:18:08PM -0500, Sean Farley wrote:
>>>> # HG changeset patch
>>>> # User Sean Farley <sean.michael.farley at gmail.com>
>>>> # Date 1408394323 18000
>>>> #      Mon Aug 18 15:38:43 2014 -0500
>>>> # Node ID fe9b72aa7e160e690813cfe4242b013fb147937e
>>>> # Parent  e1ab9da20be237323a1340efa16b58b03525596f
>>>> templater: add a method to list labels in a namespace
>>>
>>> I don't quite see the why of this series - is it so we can add other
>>> types of labels to a changeset without having to do a bunch of
>>> tapdancing? How would that be useful?
>>>
>>> (The generality is kind of nice, and I can sort of see a use for
>>> remotebranches in that a remotebranch could become a non-tag label,
>>> but I'm not sure I'm sold that it'd be worth doing there, because then
>>> you'd still have to wire in some lookup mechanics.)
>>
>> Yep, you guessed it. This series sprouted from my work on remotebranches
>> (to add bookmark support). The "why" of this series is to turn off the
>> flood of local tags (hg-git, remotebranches, etc.)
>>
>> The key features of adding this machinery to core:
>>
>> - no more polluting the output of 'hg tags'
>> - automatic template keywords / functions (see patches 11-12)
>> - displaying correctly in the log (see patch 7)
>> - automatic tab completion (see patch 9)
>> - automatic support for color (see patch 7)
>>
>> Now, all an extension would have to do is (actual test code I used):
>>
>>     repo.label("foo", "f1", repo['8a6a86c9a5b5'].node())
>>     repo.label("foo", "f2", repo['8a6a86c9a5b5'].node())
>>     repo.label("bar", "b1", repo['8a6a86c9a5b5'].node())
>>     repo.label("bar", "b2", repo['8a6a86c9a5b5'].node())
>>
>> And they would get all the nice coloring, tab completion, and templating
>> without having to add that themselves (though, you could certainly add
>> more fancy things).
>>
>> For example, imagine that the bugzilla extension could add all ticket
>> numbers to known commits:
>>
>>     repo.label("tickets", "issue1234", repo[foo].node())
>>
>> And in the command line:
>>
>>     $ hg up issue<tab>
>> issue1234 etc.
>>
>> Anyway, those are just some ideas.
>
> This is very cool. In fact this past couple of weeks I have been
> working on a small extension of may own that I am (was?) going to call
> "hgmarkers" that was meant to let you add arbitrary "markers" (I also
> considered calling them "labels") to revisions. I was using a
> "ini-like" file to store those markers, but your solution could be
> cleaner.

Thanks! Each plugin would have to store its own file of labels / markers
since this dictionary does not persist across invocations of hg.

> One important feature of this extension of mine is that a single
> marker can be applied to multiple revisions (actually you can even
> associate a revset to a marker). Would this be possible to do using
> this repo.label command? That is, could I do:
>
>      repo.label("foo", "f1", repo['8a6a86c9a5b5'].node())
>      repo.label("foo", "f1", repo['1d875217f959'].node())
>
> And have both revisions labelled foo/f1?

Currently, no, but let's save this discussion for after we decide on a
name and get some basic functionality first.


More information about the Mercurial-devel mailing list