On Tue, Dec 4, 2018 at 10:22 AM Duy Nguyen <pclo...@gmail.com> wrote: > > On Tue, Dec 4, 2018 at 6:45 PM Elijah Newren <new...@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.
