Hi Ævar,
On Thu, 27 Sep 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Sep 27 2018, Nickolai Belakovski wrote:
>
> > Will do re: screenshot when I get home, although it's pretty easy to
> > imagine, the git branch output will have one other branch colored in green,
> > bit without the asterisk
Jeff King writes:
> Alternatively, %(HEAD) could return "*" or "+" depending on whether it's
> the current worktree head. That would mildly break an existing format
> like:
>
> %(if)%(HEAD)%(then) *%(color:green)%(end)%(refname)
>
> since it would start coloring worktree HEADs the same way. It
On Thu, Sep 27, 2018 at 10:35:11PM +0100, Rafael Ascensão wrote:
> git branch has --format, but there's no way (at least to my knowledge)
> to define a value in gitconfig to be used by $git branch.
Oh, you're right. I was thinking of the branch.sort we just added in
v2.19.
I agree that having
On Thu, Sep 27, 2018 at 02:22:49PM -0700, Junio C Hamano wrote:
> The only comment I have is that I strongly suspect we will regret if
> we used an overly bland "worktree" to a rather narrrow "is this ref
> checked out in any worktree?" when we notice we want to learn other
> things that are
On Thu, Sep 27, 2018 at 03:35:59PM -0400, Jeff King wrote:
> On Thu, Sep 27, 2018 at 08:28:04PM +0100, Rafael Ascensão wrote:
> > But if we're open to change how branches are displayed maybe a config
> > option like branch.format (probably not the best name choice) that can
> > be set to the
Jeff King writes:
> On Thu, Sep 27, 2018 at 03:35:59PM -0400, Jeff King wrote:
>
>> now, we could do:
>>
>> %(if)%(HEAD)%(then)* %(color:bold green)
>> %(else)%(if)%(worktree)%(then)+ %(color:green)
>> %(else) %(end)%(end)
>>
>> (respecting the user's color config, of course, rather
On Thu, Sep 27, 2018 at 01:16:19PM -0700, Nickolai Belakovski wrote:
>
> Not to hijack my own thread, but FWIW git branch -r shows remote
> branches in red, but old/new status of a remote branch is ambiguous
> (could have new stuff, could be out of date). Also, git branch -vv
> shows remote
Not to hijack my own thread, but FWIW git branch -r shows remote
branches in red, but old/new status of a remote branch is ambiguous
(could have new stuff, could be out of date). Also, git branch -vv
shows remote tracking branches in blue. One could argue it should be
red since git branch -r is in
On Thu, Sep 27 2018, Rafael Ascensão wrote:
> On Thu, Sep 27, 2018 at 02:17:08PM -0400, Jeff King wrote:
>> Do we want to limit this to git-branch, though? Ideally any output you
>> get from git-branch could be replicated with for-each-ref (or with
>> a custom "branch --format").
>>
>> I.e.,
On Thu, Sep 27, 2018 at 03:35:59PM -0400, Jeff King wrote:
> now, we could do:
>
> %(if)%(HEAD)%(then)* %(color:bold green)
> %(else)%(if)%(worktree)%(then)+ %(color:green)
> %(else) %(end)%(end)
>
> (respecting the user's color config, of course, rather than hard-coded
> colors).
>
>
On Thu, Sep 27, 2018 at 08:28:04PM +0100, Rafael Ascensão wrote:
> On Thu, Sep 27, 2018 at 02:17:08PM -0400, Jeff King wrote:
> > Do we want to limit this to git-branch, though? Ideally any output you
> > get from git-branch could be replicated with for-each-ref (or with
> > a custom "branch
On Thu, Sep 27, 2018 at 02:17:08PM -0400, Jeff King wrote:
> Do we want to limit this to git-branch, though? Ideally any output you
> get from git-branch could be replicated with for-each-ref (or with
> a custom "branch --format").
>
> I.e., could we have a format in ref-filter that matches HEAD,
On Thu, Sep 27, 2018 at 11:39:26AM -0700, Nickolai Belakovski wrote:
> Thanks for the feedback Peff. I actually agree with all your points.
> I'd considered an approach like what you proposed, but rejected it for
> the first iteration in an effort to keep scope limited and see what
> kind of
Thanks for the feedback Peff. I actually agree with all your points.
I'd considered an approach like what you proposed, but rejected it for
the first iteration in an effort to keep scope limited and see what
kind of feedback I'd get overall (like would people even want this?).
This is a much
On Thu, Sep 27, 2018 at 08:13:13AM -0700, Nickolai Belakovski wrote:
> In order to more clearly display which branches are active, the output
> of git branch is modified to colorize branches checked out in any linked
> worktrees with the same color as the current branch.
I think the goal makes
On Thu, Sep 27 2018, Nickolai Belakovski wrote:
> Will do re: screenshot when I get home, although it's pretty easy to
> imagine, the git branch output will have one other branch colored in green,
> bit without the asterisk (for one linked worktree) :)
>
> Also will do re: changing comments to
On Thu, Sep 27, 2018 at 5:15 PM Nickolai Belakovski
wrote:
>
> In order to more clearly display which branches are active, the output
> of git branch is modified to colorize branches checked out in any linked
> worktrees with the same color as the current branch.
My first thought was "how do I
Will do re: screenshot when I get home, although it's pretty easy to
imagine, the git branch output will have one other branch colored in
green, bit without the asterisk (for one linked worktree) :)
Also will do re: changing comments to /**/ (didn't know // was from
C++, TIL) and I'll clean up
On Thu, Sep 27 2018, Nickolai Belakovski wrote:
> In order to more clearly display which branches are active, the output
> of git branch is modified to colorize branches checked out in any linked
> worktrees with the same color as the current branch.
>
> This is meant to simplify workflows
In order to more clearly display which branches are active, the output
of git branch is modified to colorize branches checked out in any linked
worktrees with the same color as the current branch.
This is meant to simplify workflows related to worktree, particularly
due to the limitations of not
20 matches
Mail list logo
