in a worktree.
The git worktree list command contains the relevant information, however
this is a much less frquently used command than git branch.
Signed-off-by: Nickolai Belakovski
---
Notes:
Travis CI results: https://travis-ci.org/nbelakovski/git/builds/432320949
builtin/branch.c | 35
wrote:
>
>
> 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 is checked out in the current worktree vs others.
On Thu, Sep 27, 2018 at 11:17 AM Jeff King wrote:
>
> 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
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
The motivation for the change is some work that I'm doing to add a
worktree atom in ref-filter.c. I wanted that atom to be able to access
all fields of the worktree struct and noticed that lock_reason wasn't
getting populated so I figured I'd go and fix that.
I figured that since get_worktrees is
no consumers of
lock_reason_valid within master, but obviously we should fix this
before they appear :)
Thoughts?
On Wed, Oct 24, 2018 at 11:56 PM Junio C Hamano wrote:
>
> nbelakov...@gmail.com writes:
>
> > From: Nickolai Belakovski
> >
> > lock_reason_valid is renamed t
On Sun, Oct 28, 2018 at 4:03 PM Eric Sunshine wrote:
>
> On Sun, Oct 28, 2018 at 5:55 PM Nickolai Belakovski
> > wrote: This was meant to be a reply to
> > https://public-inbox.org/git/cac05386f1x7tspr6kgkulwewsmdiq4vktf5rxahvzpkwbmx...@mail.gmail.com/T/#m8898c8f7c68e1ea234aca2
On Sun, Oct 28, 2018 at 9:01 PM Eric Sunshine wrote:
>
> On Sun, Oct 28, 2018 at 9:11 PM Nickolai Belakovski
> wrote:
> > I would also suggest renaming is_worktree_locked to
> > worktree_lock_reason, the former makes me think the function is
> > returning a boole
On Sun, Oct 28, 2018 at 8:52 PM Junio C Hamano wrote:
>
>
> If the field "reason" should always be populated, there is *no*
> reason why we need the "valid" boolean. They work as a pair to
> realize lazy population of rarely used field. The lazy evaluation
> technique is used as an optimization
I think if we move to making this atom just store worktree path, that
needs to be implemented as a hashmap of refname->wtpath, which would
also solve this string_list issue, correct? Just making sure I'm not
missing something before I submit another patch.
On Tue, Nov 13, 2018 at 2:38 AM Junio C
OK, I see 3 votes for cyan and 4-5 people participating in the thread,
so I'll make it cyan in the next revision.
On Tue, Nov 13, 2018 at 3:49 PM Jeff King wrote:
>
> On Mon, Nov 12, 2018 at 06:07:18PM +, Rafael Ascensão wrote:
>
> > On Mon, Nov 12, 2018 at 07:14:23AM -0500, Jeff King wrote:
11 matches
Mail list logo
