From: Junio C Hamano <gitster@pobox.com>
To: Chris Torek <chris.torek@gmail.com>
Cc: Craig H Maynard <chmaynard@me.com>, Git Community <git@vger.kernel.org>
Subject: Re: Orphan branch not well-defined?
Date: Fri, 24 Nov 2023 11:12:00 +0900 [thread overview]
Message-ID: <xmqqplzz99xr.fsf@gitster.g> (raw)
In-Reply-To: <xmqqwmu79ac4.fsf@gitster.g> (Junio C. Hamano's message of "Fri, 24 Nov 2023 11:03:23 +0900")
Junio C Hamano <gitster@pobox.com> writes:
> Chris Torek <chris.torek@gmail.com> writes:
>
>> ** Unborn Branch is the better term **
>
> Yes, To orphan is a verb that denotes the act of becoming on an
> unborn branch, and a few references to "orphan branch" in our
> documentation are misuses of the word, I would have to say.
To be fair, the use of verb "orphan" by the folks first designed the
"checkout --orphan" does make quite a lot of sense and it is very
much consistent with the fact that the operation leaves the index
and the working tree intact (unlike "switch --orphan" that empties
the contents, which came much later).
The intended use case was that the user had the current set of
contents that is desirable with history that is undesirable behind
it, and wanted to part with the baggage^Whistory while keeping the
end state. The operation was meant to be the first step to create a
"parent-less" (aka "orphaned" from the parents in the original
history) commit that records the desired state. It is the reason
why "checkout --orphan" keeps the contents intact and moves the HEAD
to be on an unborn branch.
next prev parent reply other threads:[~2023-11-24 2:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 0:28 Orphan branch not well-defined? Craig H Maynard
2023-11-22 1:08 ` Junio C Hamano
2023-11-22 1:42 ` Chris Torek
2023-11-24 2:03 ` Junio C Hamano
2023-11-24 2:12 ` Junio C Hamano [this message]
2023-11-24 2:27 ` Eric Sunshine
2023-11-24 2:31 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqplzz99xr.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=chmaynard@me.com \
--cc=chris.torek@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).