On Thu, Jan 19, 2017 at 07:26:30PM +0700, Nguyễn Thái Ngọc Duy wrote:
> This is most useful when you fork your branches off a remote ref and
> rely on ref decoration to show your fork points in `git log`. Then you
> do a "git fetch" and suddenly the remote decoration is gone because
> remote refs are moved forward. With this, we can still see something
> like "origin/foo@{1}"
>
> This is for remote refs only because based on my experience, docorating
> local reflog is just too noisy. You will most likely see HEAD@{1},
> HEAD@{2} and so on. We can add that as a separate option in future if we
> see a need for it.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
> ---
> I've been using this for many weeks and it has proven its usefulness
> (to me). Looks like good material to send upstream.
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.
-Peff