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. Best Wishes Phillip > I was wondering if instead of the empty index, we mark on files from > <start-point> as intent-to-add. That way "git commit -a" achieves the > same as before, but you could still carefully craft the new index and > "git commit". Dunno. Not going to implement it unless somebody says > something, since I rarely (if ever?) use --orphan. > > I may need someone to come up with a convincing commit message > too. All I've got is "I've been told this is a good thing to do" :) > -- > Duy >
