As previously discussed in the "operation" thread [1]. I think we want to use "operation" metadata instead of introducing flags, "obsfate" and/or "verb" as new concepts. Practically "rebased as X" / "histedited as X" is more friendly to end-user than just "rewritten as X".
With "operation" concept available, template could be just raw fields of an obsmarker like user, data, successors, operation etc without needing another layer of indirection (obsfate). I think that's simpler for users to understand. [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-May/097678.html Excerpts from Boris Feld's message of 2017-07-12 15:44:13 +0200: > On Wed, 2017-07-12 at 00:06 +0900, Yuya Nishihara wrote: > > On Tue, 11 Jul 2017 11:16:03 +0200, Boris Feld wrote: > > > Obsfate has a difficult task: summarize the obsolescence history > > > (potentially spanning multiple obs-markers), aggregating the > > > different > > > values and all of this in multiple dimensions when there's a > > > divergence. > > > > > > This template seems quite complex, it felt complex during > > > implementation using templates. I tried finding an existing > > > template > > > that was close to this complexity, successorssets was close but > > > obsfate > > > adds one more layer of nesting, so I didn't find a good example to > > > mimic. > > > > > > I'm pretty sure that implementing obsfate cleanly with the template > > > engine can be done, but after spending several days, I'm afraid I > > > won't > > > be able to do it on my own. For example, I wasn't able to > > > successfully > > > format the users list using templates, I tried doing this: > > > > > > hg log -G -T '{obsfate % "obsolete: {get(obsfate, "verb")} by > > > {join(get(obsfate, "users"), ', ')}\n"}' > > > > > > Lately, I was thinking about sending a V2 that, instead of > > > returning > > > the formatted string, would returns an _hybrid object: > > > > > > - return _obsfateprinter(values, repo, repo.ui) > > > + gen = _obsfateprinter(values, repo, repo.ui) > > > + return _hybrid(gen, values, None, None) > > > > > > This way people would be able to start customizing it (with > > > template > > > function "get") and we would be able to improve the implementation > > > with > > > potential syntactic sugar addition in the template engine. > > > > Well, I don't have expertise in the obsolete thingy, though I'm > > (unfortunately) > > a template expert. > > > > Guessing from the PATCH 4, which has the following functions, > > > > obsfatedata: ctx => [succs, ...] => [(succs, markers), ...] > > > > maybe we'll want a template function which converts 'succs' to > > 'markers' ? > > Let's call it 'relatedmarkers' here. > > > > relatedmarkers: succs => [marker, ...] (where marker is a _hybrid > > dict) > > > > Then, a part of {obsfate} could probably be written as: > > > > {successorsets % "{relatedmarkers(successorset) > > % "{get(marker, "verb")} ..."}"} > > I hadn't thought about splitting the template into several templates > functions, it's a good idea!. > > One small, but important detail: the verb, users list and dates are > computed from the markers list. Something like this might work, what do > you think? > > {successorsets % "{obsfateverb(successorset)} by > {obsfateusers(successorset)} as {join(get(successorset, 'successors'), > ', ')}"} > > Would it be possible to keep the current {obsfate} template? It is easy > to use for users who are OK with the default obsfate output format > (which could be updated of course). > > Also I've almost successfully reproduce the obsfate output "by hand" > with: > > $ hg log -r 34177 --hidden -v -T "{obsfate}" > rewritten by Boris Feld <boris.f...@octobus.net> as e18d8e61b726 (at > 2017-07-06 23:47 +0200) > > $ hg log -r 34177 --hidden -T '{obsfate % "{get(obsfate, "verb")} by > {join(get(obsfate, "users"), ", ")} as {get(obsfate, "successors")} (at > {get(obsfate, "min_date")|isodate})\n"}' > rewritten by Boris Feld <boris.f...@octobus.net> as e18d8e61b726 (at > 2017-07-06 23:47 +0200) > > > > I think that's similar to what Jun suggested. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
