Re: [PATCH] branch: colorize branches checked out in a linked working tree the same way as the current branch is colorized
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Sep 27, 2018, 15:33 UTC
- Message-ID
- <87y3bnhs5a.fsf@evledraar.gmail.com>
- In-Reply-To
- <CAC05386q2iGoiJ_fRgwoOTF23exEN2D1+oh4VjajEvYQ58O1TQ@mail.gmail.com>
On Thu, Sep 27 2018, Nickolai Belakovski wrote:
Show 15 quoted lines
> 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.
Show 16 quoted lines
> 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.