On Fri, Sep 23, 2022 at 05:58:56PM -0400, Jeff King wrote: > I don't think you even really need the regexp. If we respect --date, > then you should be able to ask for --date=format:%Y-%m. Hmm I tried passing in --date=format:... to my patched shortlog command along with setting some date placeholder like "... %cd ..." in the code, but it's not picking up on the format. Do you know how the date format can be wedged into the format_commit_message(...) "format" argument? > Unfortunately there's no way to specify the format as part of the > placeholder. The for-each-ref formatter understands this, like: > > %(authordate:format:%Y-%m) > > I wouldn't be opposed to teaching the git-log formatter something > similar. Oh that would solve my problem... Would it be a hefty effort to teach this to the git-log formatter? > But there's something else interesting going on in Jack's patch, which > is that he's not just introducing the date-sorting, but also that it's > used in conjunction with other sorting. So really the intended use is > something like: > > git shortlog --group:author --group:%Y-%m Yes I sort of stumbled on this and realized that this way I wouldn't have to touch the actual sorting or grouping functionality at all, which was already working properly. I just needed to reformat the shortlog message to include the year and/or month in a way that kept things consistent. > I think we'd want to allow the general form to be a series of groupings. > In the output from his patch it looks like: > > 2022-09 Jeff King > some commit message > another commit message > > I.e., the groups are collapsed into a single string, and unique strings > become their own groups (and are sorted in the usual way). > > If you give up the regex thing, then that naturally falls out as > (imagining we learn about authordate as a placeholder): > > git shortlog --group='%(authordate:format=%Y-%n) %an' > > without having to implement multiple groupings as a specific feature > (which is both more code, but also has user-facing confusion about when > --group overrides versus appends). That also skips the question of which > --group-by-regex applies to which --group-by-value. > > I do agree the regex thing is more flexible, but if we can't come up > with a case more compelling than subsystem matching, I'd just as soon > add %(subject:subsystem) or similar. :) > > -Peff I like this idea too. Since it requires a larger re-implementation, maybe I can pursue this going forward. I assume if we did this we would keep the existing group options like "--group=author" as shortcuts, and refactor them behind the scenes to use the new method. If so it may be useful to add my originally suggested options of "--group=year" and "--group=month" as well for convenient default time-based groupings. How do you feel about me submitting a v3 patch of my initial suggested implementation of new group options for year and month? Then going forward I can work on generalizing the grouping feature the way Peff suggested. -Jack
