Re: [PATCH] branch: colorize branches checked out in a linked working tree the same way as the current branch is colorized

From: Nickolai Belakovski <nbelakovski@gmail.com>
To: avarab@gmail.com
Cc: git@vger.kernel.org
Subject: Re: [PATCH] branch: colorize branches checked out in a linked working tree the same way as the current branch is colorized
Date: Thu, 27 Sep 2018 10:46:39 -0700	[thread overview]
Message-ID: <CAC05387jxW-LKk8Qk6Tt50PHi62YpBGQpDFyx_W4m+ROZbej0g@mail.gmail.com> (raw)
In-Reply-To: <87y3bnhs5a.fsf@evledraar.gmail.com>

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 the comments to remove some of the more
obvious ones, but I'll try to keep a comment explaining the basic flow
of creating a nest if statement to evaluate worktree refs for color.

And yes, I copy/pasted into gmail. I was having trouble setting up
send-email, but I think I may have it figured out now. Should I create
a new thread with send-email? Or maybe reply to this one (I can do
that by specifying the Message-ID to reply to right? This is my first
time using this workflow, so I appreciate your patience :) )?

Thanks for the feedback!

On Thu, Sep 27, 2018 at 8:33 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> 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.
> >
> > This is meant to simplify workflows related to worktree, particularly
> > due to the limitations of not being able to check out the same branch in
> > two worktrees and the inability to delete a branch checked out in a
> > worktree. When performing branch operations like checkout and delete, it
> > would be useful to know more readily if the branches in which the user
> > is interested are already checked out 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 <nbelakovski@gmail.com>
>
> Sounds cool, b.t.w. would be neat-o to have some screenshot uploaded to
> imgur or whatever just to skim what it looks like before/after.
>
> > diff --git a/builtin/branch.c b/builtin/branch.c
> > index 4fc55c350..65b58ff7c 100644
> > --- a/builtin/branch.c
> > +++ b/builtin/branch.c
> > @@ -334,11 +334,36 @@ static char *build_format(struct ref_filter
> > *filter, int maxwidth, const char *r
> >         struct strbuf local = STRBUF_INIT;
> >         struct strbuf remote = STRBUF_INIT;
> >
> > -       strbuf_addf(&local, "%%(if)%%(HEAD)%%(then)* %s%%(else)  %s%%(end)",
> > -                   branch_get_color(BRANCH_COLOR_CURRENT),
> > -                   branch_get_color(BRANCH_COLOR_LOCAL));
> > -       strbuf_addf(&remote, "  %s",
> > -                   branch_get_color(BRANCH_COLOR_REMOTE));
> > +       // Prepend the current branch of this worktree with "* " and
> > all other branches with "  "
>
>
> We use /* ... */ C comments, not C++-style // (well, it's in C now, but
> not the ancient versions we need to support).
>
> It also seems all of this patch was copy/pasted into GMail or something,
> it has wrapping and doesn't apply with "git am".
>
> Also most/all of these comments I'd say we could better do without,
> i.e. the ones explaining basic code flow that's easy to see from the
> code itself.