From: Duy Nguyen <pclouds@gmail.com>
Date: Mon, 18 Mar 2019 12:06:25 GMT
Subject: Re: [PATCH v3 10/21] checkout: split part of it to new command 'switch'
Message-ID: <CACsJy8Dfy4csm5xpGwz6EZXqN+uMFmf4woEPTZ2WjbeDTa-9Sw@mail.gmail.com>
In-Reply-To: <xmqqr2b56ir6.fsf@gitster-ct.c.googlers.com>

On Mon, Mar 18, 2019 at 9:03 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> > I don't see why <start-point> even makes sense to use with --orphan;
> > you should error if both are given, IMO.  The point of --orphan is to
> > create some entirely new history.  So, I'd expect "git switch --orphan
> > <new-branch>" to:
> >   * not create refs/heads/<new-branch>
> >   * set HEAD to refs/heads/<new-branch>
> >   * empty all tracked files from the working tree.
> >   * empty the index
> >
> > Alternatively, you could allow <start-point> to be passed with
> > --orphan, adjusting the above steps so that both the index and the
> > working tree are switched to match <start-point>, but ONLY if
> > <start-point> defaults to the empty tree when --orphan is passed.
>
> Do you mean that it's like <start-point> is not really a start-point
> but is an initial tree, i.e.
>
>         switch --orphan --initial-tree=<tree-ish> <new-branch>
>
> is a mere short-hand for
>
>         switch --orhpan <new-branch> &&
>         restore --from-tree=<tree-ish> .
>
> I think that does make sense, but at the same time, I think a major
> reason why people say "checkout does too many things depending on
> the arguments and conext to be easily explained" is exactly due to
> its many "if you give X, it is like writing this longer command
> sequence" short hands, so...

Yeah <start-point> is optional and probably only useful for people who
do a lot of --orphan. I did think if there's any other command that
could be a better host for this orphan branch creation. No such luck.

PS. There's one small difference between 'switch --orphan <new-branch>
<tree-ish>' and your switch/restore combination: the latter refuses if
you have any local changes because it has to remove all tracked files
first, while the former only refuses when the local changes are
outside <tree-ish>. If path A will be tracked by <tree-ish>, then
whatever changes in there may stay.
-- 
Duy