On 04/08, Eric Sunshine wrote:
> On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer <t.gummerer@xxxxxxxxx> wrote:
> > This round should fix all the UI issues Eric found in the last round.
> > The changes I made in a bit more detail:
> >
> > - added a new commit introducing a new hidden --show-new-head-line
> > flag in 'git reset'. This is used to suppress the "HEAD is now at
> > ..." line that 'git reset --hard' usually prints, so we can replace
> > it with our own "New worktree HEAD is now at ..." line instead,
> > while keeping the progress indicator for larger repositories.
>
> As with Junio, I'm fine with this hidden option (for now), however, I
> think you can take this a step further. Rather than having a (hidden)
> git-reset option which suppresses "HEAD is now at...", instead have a
> (hidden) option which augments the message. For example,
> --new-head-desc="New worktree" would make it output "New worktree HEAD
> is now at...". Changes to builtin/reset.c to support this would hardly
> be larger than the changes you already made.
>
> The major benefit is that patch 3/6 no longer has to duplicate the
> code from builtin/reset.c:print_new_head_line() just to print its own
> "New worktree HEAD is now at..." message. (As for the argument that
> "git worktree add" must duplicate that code because it wants the
> message on stderr, whereas git-reset prints it to stdout, I don't see
> why git-worktree puts those messages to stderr in the first place. As
> far as I can tell, it would be equally valid to print them to stdout.)
I didn't think of that, but I think that's nicer indeed. Will change.
This will also be nicer when we're in a position to remove the hidden
option and do all of this with internal functions. Then we can just
re-use the new function that also takes a prefix at that point (after
moving the function to 'libgit.a' of course.
> > Some examples of the new UI behaviour here for reference:
> >
> > - guess-remote mode
> >
> > $ git worktree add --guess-remote ../next
> > Creating branch 'next'
> > Branch 'next' set up to track remote branch 'next' from 'origin'.
> > New worktree HEAD is now at caa68db14 Merge branch 'sb/packfiles-in-repository' into next
> >
> > - original dwim (create a branch based on the current HEAD)
> >
> > $ git worktree add ../test
> > Creating branch 'test'
> > New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
> >
> > - new dwim (check out existing branch)
> >
> > $ git worktree add ../test
> > Checking out branch 'test'
> > New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
> >
> > - no new branch created
> >
> > $ git worktree add ../test2 origin/master
> > New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
>
> I like the "creating" or "checking out" messages we now get for all
> the DWIM cases. I wonder if it would make sense to print "Checkout out
> blah..." for this case too. It's certainly not necessary since the
> user specified <commit-ish> explicitly, but it would make the UI even
> more consistent, and address your subsequent comment about missing
> context above the "Checking out files: ...%" line for this case.
> Thoughts?
Let me think through some of the cases here, of 'git worktre add
<path> <commit-ish>' with various flags and what the UI would be with
that added:
- no flags:
$ git worktree add ../test origin/master
Checking out 'origin/master'
Checking out files: ...%
New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
- -b branch:
$ git worktree add -b test ../test origin/master
Creating branch 'test'
Checking out 'origin/master'
Checking out files: ...%
New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
Would we want to omit the "Checking out ..." here? I'm leaning
towards yes, but dunno?
- --no-checkout
$ git worktree add --no-checkout test ../test origin/master
New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
- Original dwim with --detach flag
$ git worktree add --detach ../test
Checking out 'c2a499e6c'
Checking out files: ...%
New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
Looking at this, I'm not sure what's best here. I'm not sure I'm a
fan of the duplicate "Checking out " message (I assume that's what you
meant above, or did you mean just "Checkout ..."?)
I als don't think it gives too much context compared to just "Checking
out files: ...%". I think it gives a bit more context when that
message is not displayed at all, as it shows whether files are checked
out or not, but if we do that, when we create a new branch, the amount
of output we'd display is getting a bit long, to the point where I
suspect users would just not read it anymore.
So I personally don't feel like this is worth it, even though it may
give some context in some cases. But I'm also far from an expert in
UI design, so if you (or others) feel this would be nicer I'm happy to
implement it :)
> > Compare this to the old UI (new dwim omitted, as there's no old
> > version of that):
>
> Thanks for contrasting the new with the old. The new output is nicer
> and more helpful.
>
> > The one thing we are loosing is a context line before "Checking out
> > files:", if no new branch is created. Personally I feel like that's
> > acceptable, as the user just used the 'git worktree add' command, so
> > it should be intuitive where those files are being checked out.
