On Mon, Mar 18, 2019 at 9:03 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> 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
