On Fri, Jan 20, 2017 at 12:23 AM, Jeff King <peff@xxxxxxxx> wrote: > I think it's a neat idea, but the actual option: > >> +--decorate-remote-reflog[=<n>]:: >> + Decorate `<n>` most recent reflog entries on remote refs, up >> + to the specified number of entries. By default, only the most >> + recent reflog entry is decorated. > > seems weirdly limited and non-orthogonal. What happens when somebody > wants to decorate other reflogs besides refs/remotes? > > We already have very flexible ref-selectors like --remotes, --branches, > etc. The generalization of this would perhaps be something like: > > git log --decorate-reflog --remotes --branches > > where "--decorate-reflog" applies to the next ref selector and then is > reset, the same way --exclude is. And it includes those refs _only_ for > decoration, not for traversal. So you could do: > > git log --decorate-reflog --remotes --remotes > > if you wanted to see use those as traversal roots, too (if this is > common, it might even merit another option for "decorate and show"). > > That's just off the top of my head, so maybe there are issues. I was > just surprised to see the "-remote" part in your option name. Imposing order between options could cause confusion, I think, if you remove --decorate-reflog leaving --remotes on by accident, now you get --remotes with a new meaning. We could go with something like --decodate-reflog=remote, but that clashes with the number of reflog entries and we may need a separator, like --decorate-reflog=remote,3. Or we could add something to --decorate= in addition to short|full|auto|no. Something like --decorate=full,reflog or --decorate=full,reflog=remote,entries=3 if I want 3 reflog entries. My hesitant to go that far is because I suspect decorating reflog won't be helpful for non-remotes. But I'm willing to make more changes if it opens door to master. -- Duy