Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

[Elijah Newren <newren@gmail.com>]

On Tue, Dec 4, 2018 at 10:22 AM Duy Nguyen <pclouds@gmail.com> wrote:
>
> On Tue, Dec 4, 2018 at 6:45 PM Elijah Newren <newren@gmail.com> wrote:
> > > > > - Two more fancy features (the "git checkout --index" being the
> > > > >   default mode and the backup log for accidental overwrites) are of
> > > > >   course still missing. But they are coming.
> > > > >
> > > > > I did not go replace "detached HEAD" with "unnamed branch" (or "no
> > > > > branch") everywhere because I think a unique term is still good to
> > > > > refer to this concept. Or maybe "no branch" is good enough. I dunno.
> > > >
> > > > I personally like "unnamed branch", but "no branch" would still be
> > > > better than "detached HEAD".
> > >
> > > Haven't really worked on killing the term "detached HEAD" yet. But I
> > > noticed the other day that git-branch reports
> > >
> > > * (HEAD detached from 703266f6e4)
> > >
> > > and I didn't know how to rephrase that. I guess "unnamed branch from
> > > 703266f6e4" is probably good enough but my old-timer brain screams no.
> >
> > Perhaps "* (On an unnamed branch, at 703266f6e4)"?
>
> This 703266f6e4 is the fork point. Once you start adding more commits
> on top of this unnamed branch, I find it hard to define it "at"
> 703266f6e4 anymore. "forked from 703266f6e4" (or even starting/growing
> from...) is probably clearest but also a bit longer.

It reports the fork point rather than the commit HEAD points to?  Ah,
I guess I never payed that close of attention before.  I actually
think "on an unnamed branch" is good enough, but if others gain value
from the extra info, then I understand the conundrum.  I'm not sure
what the use or rationale is for the fork point, though, so I feel
slightly at a loss to try to describe this extra piece of info.