Re: [PATCH 00/28] Use main as default branch name

From: Philip Oakley <philipoakley@iee.email>
Date: Nov 22, 2020, 20:18 UTC
Message-ID: <9c285212-3d64-f90c-1b66-9c7172f77ddb@iee.email>
In-Reply-To: <87zh397cfh.fsf@osv.gnss.ru>

On 22/11/2020 13:23, Sergey Organov wrote:

Show 21 quoted lines

>>>> The latter (i.e. you are not on a branch) does not grow any branch.
>>> That's one way of looking at it, resulting in this "detached HEAD"
>>> thingy that is too technical for the git user proper, I think. Moreover,
>>> it immediately raises the question: if it doesn't grow any branch, /what/
>>> does it grow?
>>>
>>> Another way of describing it, that I prefer, is that you /are/ on an
>>> /unnamed/ branch and new commits grow this particular /unnamed/ branch.
>>> No need not only for "detached", but even for "HEAD" to be known to the
>>> user to get the idea, I think.
>> I don't think we can start like this and continue with a commit on top
>> of the orphaned 'unnamed' branch. (Not tried it though..)
> I rather believe we can, no problems, and that's why "detached HEAD" behaves
> exactly as unnamed branch would.
>
> To make it obvious "detached HEAD" is in fact a subset of the usual
> case, imagine that "detached HEAD" is rather first implemented by
> pointing to a branch reference with a hidden name that in turn points to
> the commit, and then this "incognito branch reference" is optimized-out
> as being invisible anyway, so HEAD now points to the commit itself.
>

Thinking about some options...

After a `git init`: We can hack HEAD to "ref: refs/heads/" (i.e. a symref to an unnamed branch) and `git status` will report "No commits yet". My PS1 will report the current branch as "()" (i.e. an empty name).

However, `git branch` reports "Failed to resolve HEAD as a valid ref.", and `git commit` reports "cannot lock ref 'HEAD': there is a non-empty directory '.git/refs/heads/' blocking reference 'refs/heads/'".

So, there could be the option to detect that unnamed ref state (no characters after the final "/") without going "Fatal:".

However there is still the potential difficulty that after the first commit on that unnamed branch we would have the difficult choice of:

- either keeping that unnamed ref/branch symref, and have nowhere to
hold the new commit name (oid), because HEAD is already acting as the
place holder for the symref,
- or we have to lose the place holder symref and place the new commit
oid into HEAD, leaving us back at the regular "detached head", but for
an as yet unnamed orphan branch.
(tested on Windows[1])

For the second case we would still need to ensure that protections are in place to avoid loosing those detached commits if the user switches/checks out to new branch based on some other oid. (for that to happen then that checkout oid must be somewhere in the unnamed branch, but the latest tip commits should need checking to prevent unexpected loss - the current warning may not be enough...)

At the moment there is a lot of 'lock-in' for the status quo, and the alternative may not be any better, and have some backward compatibility issues, though those may be overstated, depending on how repos are being 'shared'.

Philip

[1] phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/unnamed () $ git version git version 2.29.2.windows.2