Hi Ævar,

On Thu, 27 Sep 2018, Ævar Arnfjörð Bjarmason wrote:

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

There is also a nice tutorial in
https://github.com/git-for-windows/git/blob/master/CONTRIBUTING.md#submit-your-patch
(which, contrary to the location, is useful for non-Windows developers,
too.)

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

IIRC GitGitGadget has no facility yet to reply to any mail it did not
generate itself (i.e. if you did not generate v1 using GitGitGadget, then
it cannot generate a v2 that replies to the previous iteration).

This might change at some stage, but I have other priorities for now.
(Which should not stop any contributor from opening a PR to scratch their
own favorite itch.)

Ciao,
Johannes

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