From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id B66811F670 for ; Thu, 19 Nov 2020 10:38:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726375AbgKSKft (ORCPT ); Thu, 19 Nov 2020 05:35:49 -0500 Received: from smtp.hosts.co.uk ([85.233.160.19]:39830 "EHLO smtp.hosts.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726073AbgKSKfs (ORCPT ); Thu, 19 Nov 2020 05:35:48 -0500 Received: from host-89-243-187-160.as13285.net ([89.243.187.160] helo=[192.168.1.37]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1kfhI2-0008i2-6E; Thu, 19 Nov 2020 10:35:47 +0000 Subject: Re: [PATCH 00/28] Use main as default branch name To: Junio C Hamano Cc: "Eric W. Biederman" , Johannes Schindelin via GitGitGadget , git@vger.kernel.org, Johannes Schindelin References: <87r1oraewl.fsf@x220.int.ebiederm.org> <1389dabc-33c9-1e65-a3de-43729a6c2e70@iee.email> From: Philip Oakley Message-ID: <7df660f2-ad74-7d1f-eb13-a0edadffbfbf@iee.email> Date: Thu, 19 Nov 2020 10:35:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On 19/11/2020 01:51, Junio C Hamano wrote: > Philip Oakley writes: > >> An alternative in the other direction is to go with the 'not currently >> on any branch' (detached at nowhere) but then require users to >> deliberately create their first branch with their chosen name. This >> moves the 'backward incompatibility' to a different place, which may be >> easier to manage. > As has already been mentioned by Peff, I do not think that is a > workable alternative, especially given that people are generally > afraid of and easily get confused by being on a detached HEAD. Yes, our use of the technical phrase 'detached HEAD' is confusing, compared with the more pleasant 'not on any branch', or 'not at a branch tip'. Such is the curse of knowledge. > > And there is no such thing as unborn detached HEAD. Existing > versions of Git would not consider a $GIT_DIR that does not have any > HEAD, which means a new repository created by such an "initially > there is no branch" version of Git cannot be accessed by any > existing versions of Git. Isn't this, essentially, because there is no 'empty/null commit' that we (HEAD) could start at? There have been a few cases where I've been 'annoyed' that we're missing that. (rather than the orphan branch approach) > > It raises the backward incompatibility of such an approach to a > whole new level that is simply unmanageable, I am afraid. OK, accepted. Philip