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... > How about: > > """ > Switching and creating branches always involves knowing the > <start-point> to begin the new branch from. Sometimes, people want to > create a new branch that does not have any commits yet; --orphan is a > flag to allow that. --orphan overrides the default of HEAD for > <start-point> instead causing us to start from an empty history. The > use of --orphan is incompatible with specifying a <start-point>. > """ With or without the short-hand to say which initial tree to populate the index from, the above description makes sense to me.
