Subject: Re: [PATCH v6 2/6] reset: introduce show-new-head-line option

From: Thomas Gummerer <[email-masked]>
Date: Mon, 2 Apr 2018 23:07:41 +0100

On 04/02, Junio C Hamano wrote:
> Thomas Gummerer <[email-masked]> writes:
> 
> > Introduce a new --show-new-head-line command line option, that
> > determines whether the "HEAD is now at ..." message is printed or not.
> > It is enabled by default to preserve the current behaviour.
> >
> > It will be used in a subsequent commit to disable printing the "HEAD is
> > now at ..." line in 'git worktree add', so it can be replaced with a
> > custom one, that explains the behaviour better.
> >
> > We cannot just pass the --quite flag from 'git worktree add', as that
> > would also hide progress output when checking out large working trees,
> > which is undesirable.
> >
> > As this option is only for internal use, which we probably don't want
> > to advertise to our users, at least until there's a need for it, make
> > it a hidden flag.
> 
> As a temporary hack, adding something like this may be OK, but in
> the longer run, I think we should (at least) consider refactoring
> "reset --hard" codepath to a freestanding and silent helper function
> so that both cmd_reset() and add_worktree() can call it and report
> the outcome in their own phrasing.

I agree that refactoring this would have been nicer.  The biggest
obstacle there is that the 'git reset' needs to run with a different
"GIT_DIR" and "GIT_WORK_TREE", which is not easy to accomplish in the
current code.

It does seem like something that would be much easier once we have
'struct repository' being passed through everywhere.  I'd rather wait
a bit more for the 'struct repository' series to land, which will
hopefully make the refactoring easier (although I didn't have time to
follow the series closely).

> And I support the decision not to advertise this as a new feature or
> an option by implementing it as hidden-bool.
> 
> This is completely offtopic tangent, but I wonder how hidden-bool or
> hidden options[] element in general interacts with the recent
> addition of helping command line completion.  Are we already doing
> the right thing?