On 03/27, Eric Sunshine wrote:
> On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer wrote:
> > Currently there is no indication in the "git worktree add" output that
> > a new branch was created. This would be especially useful information
> > in the case where the dwim of "git worktree add " kicks in, as the
> > user didn't explicitly ask for a new branch, but we create one from
> > them.
>
> Failed to notice this last time around: s/from/for/
>
> Perhaps Junio can tweak it when queuing.
>
> > Print some additional output showing that a branch was created and the
> > branch name to help the user.
> >
> > This will also be useful in the next commit, which introduces a new kind
>
> It's no longer the _next_ commit which does this. Perhaps say instead
> "a subsequent commit". (Again, perhaps Junio can tweak it since it's
> not worth a re-roll.)
Right, will fix.
> > of dwim-ery of checking out the branch if it exists instead of refusing
> > to create a new worktree in that case, and where it's nice to tell the
> > user which kind of dwim-ery kicked in.
> >
> > Signed-off-by: Thomas Gummerer
> > ---
> > diff --git a/builtin/worktree.c b/builtin/worktree.c
> > @@ -318,6 +318,9 @@ static int add_worktree(const char *path, const char
> > *refname,
> > + if (opts->new_branch)
> > + fprintf_ln(stderr, _("creating branch '%s'"),
> > opts->new_branch);
>
> I didn't think of this before, but what happens with the original
> dwim-ery you added which checks out a remote branch matching the
> worktree name if no such local branch exists? I was wondering if we'd
> want to see a distinct and more informative message in that case, such
> as "creating branch '%s' from remote '%s'" or something. However, I
> see that we're already getting a message:
>
> Branch 'foo' set up to track remote branch 'foo' from 'origin'.
> creating branch 'foo'
> new worktree HEAD is now at d3adb33f boople
>
> which is a bit weird since tracking appears to be set up before the
> branch itself is created. I thought that this was another UI
> regression of the sort I mentioned in [1], however, the messages were
> out of order even before the current patch series:
Yeah I agree this is a bit odd. I did think about this, and the main
reason why I didn't change this by passing the '--quiet' flag to 'git
branch' which we call in the 'add()' function is to keep the
information about the remote tracking.
Looking at where this information actually comes from, there's
multiple different ways we'd have to distinguish to print this
information properly.
Now that I put some more thought into this, I think there are a couple
of ways to solve this, the easiest and cleanest of which would
probably be to run 'git branch' through 'pipe_command', save the
output and print it after the "creating branch 'foo'" message.
> Branch 'foo' set up to track remote branch 'foo' from 'origin'.
> Preparing foo (identifier foo)
> Checking out files: 100% (/), done.
> HEAD is now at d3adb33f boople
>
> This highlights another regression introduced by this series. Patch
> 1/6 suppresses the "Checking out files:" message, which is a bit
> unfortunate for decent sized worktrees. I'm not sure I'm entirely
> happy about that loss. Thoughts?
Tbh I never really noticed the "Checking out files" output, because
the repositories I used day to day are usually of a smaller size,
where checking out the files takes less than a second, so I would
never even notice this output.
But while I don't care about it, others may, so I think it would be
better to preserve this output. Maybe the best way to do that would
be to not use 'run_command' to run 'git reset --hard', but to instead
replace that with the internal functions.
I haven't actually looked at how hard this would be, but I'm guessing
this may be the best option to avoid this UI regression. I'll play
with this some more and see what I can come up with, and send a
re-roll hopefully in a few days.
Thanks for your review!
> [1]:
> https://public-inbox.org/git/CAPig+cT8i9L9kbhx=b0sg4_qyndoedpw-1xypm9xzbqpmqr...@mail.gmail.com/
>
> > fprintf(stderr, _("new worktree HEAD is now at %s"),
> > find_unique_abbrev(commit->object.oid.hash,
> > DEFAULT_ABBREV));
