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 <hidden>
Date: 2018-09-27 15:33:27
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 <redacted>
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.
quoted hunk ↗ jump to hunk
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.