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
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
>>>
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
>>
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"
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
>> +
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
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}"
7 matches
Mail list logo