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

Reply via email to