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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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 /**/ (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?

You'd run git format-patch master..your-topic with
--subject-prefix="PATCH v2" and
--in-reply-to="<CAC05386q2iGoiJ_fRgwoOTF23exEN2D1+oh4VjajEvYQ58O1TQ@mail.gmail.com>". Then
it'll show up in reply to your v1.

You can also for an easier experience do this via GitGitGadget, see
https://github.com/gitgitgadget/gitgitgadget looking at its code it
seems to have some way to reference a Message-ID, but I don't know how
to trigger that.

> This is my first time using this workflow, so I appreciate your
> patience :) )?

No worries, happy to help.

> 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.
>>