Re: [PATCH] log: new option decorate reflog of remote refs

2017-01-21 Thread Jeff King
On Sat, Jan 21, 2017 at 07:48:50PM +0700, Duy Nguyen wrote: > OK. Next question, how do we deal with the reflog count (i..e the > argument of --decorate-remote-reflog). Should it be shared for all ref > type, or can be specified differently for remote, local and tags? I'm > leaning towards the

Re: [PATCH] log: new option decorate reflog of remote refs

2017-01-21 Thread Duy Nguyen
On Sat, Jan 21, 2017 at 5:00 AM, Jacob Keller wrote: > On Fri, Jan 20, 2017 at 6:30 AM, Jeff King wrote: >>> Imposing order between options could cause confusion, I think, if you >>> remove --decorate-reflog leaving --remotes on by accident, now you get >>>

Re: [PATCH] log: new option decorate reflog of remote refs

2017-01-20 Thread Jacob Keller
On Fri, Jan 20, 2017 at 6:30 AM, Jeff King wrote: >> 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 >>

Re: [PATCH] log: new option decorate reflog of remote refs

2017-01-20 Thread Jeff King
On Fri, Jan 20, 2017 at 05:55:21PM +0700, Duy Nguyen wrote: > > 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"

Re: [PATCH] log: new option decorate reflog of remote refs

2017-01-20 Thread Duy Nguyen
On Fri, Jan 20, 2017 at 12:23 AM, Jeff King wrote: > I think it's a neat idea, but the actual option: > >> +--decorate-remote-reflog[=]:: >> + Decorate `` most recent reflog entries on remote refs, up >> + to the specified number of entries. By default, only the most >> +

Re: [PATCH] log: new option decorate reflog of remote refs

2017-01-19 Thread Jeff King
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

[PATCH] log: new option decorate reflog of remote refs

2017-01-19 Thread Nguyễn Thái Ngọc Duy
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}"