On Thu, Mar 14, 2019 at 6:02 PM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > > On 14/03/2019 09:17, Duy Nguyen wrote: > > On Tue, Mar 12, 2019 at 01:28:35PM -0400, Eric Sunshine wrote: > >>>> Again, not much of a datapoint, but I do use --orphan periodically. > >>>> The idea of "fixing" the behavior so that --orphan starts with a clean > >>>> slate is certainly appealing (since it matches how I've used orphan > >>>> branches in each case). > >>> > >>> The only three people who have commented on --orphan in this thread > >>> all apparently feel the same way: the current behavior is wrong. > >>> Maybe we can switch it to start with an empty index after all? > >> > >> Starting empty may match intuition better. (More importantly, perhaps, > >> it's harder to come up with a use-case for --orphan which doesn't > >> involve starting with a clean slate.) > > > > OK so the new --orphan description would be like this, right? > > > > --8<-- > > --orphan <new-branch>:: > > Create a new 'orphan' branch, named `<new-branch>`. If > > `<start-point>` is specified, the working tree is adjusted to > > match it. The index remains empty (i.e. no file is tracked). > > -->8-- > > What happens if no <start-point> is given? Do you end up with an empty > working tree or the current one? I'd lean towards an empty working tree > (with a check that there are no uncommitted changes, users can use > `restore` if they want some of the files back) but that is inconsistent > with the implicit <start-point> of -c. I was thinking default <start-point> is HEAD. But yeah empty tree makes more sense since you can always say "switch --orphan <branch> HEAD" but can't really say "give me an empty tree". -- Duy
