Junio C Hamano <gitster@xxxxxxxxx> writes:
> GitTips page of git wiki mentions this under "a new branch that has no
> ancestor", and speaks of a way to add "a new and empty branch". Scott
> Chacon also creates "new empty branches" in the community book.
By the way, I would actually suggest updating these web pages not to make
it sound as if it is a good thing to create a new "empty" history (aka "no
common paths") in an existing repository. Git wiki lists "create in a
separate repository and push into the same" as "The easy way", as if it is
easy-but-amateurish, making it sound as if experts should use different
ways for extra coolness point. People may think that having branches like
'man' and 'html' in the same repository as I do is somehow cool, but it is
a total misconception. That part of Git wiki page should be reworded to
reduce user confusion; "The easy way" is actually "the one true way".
While it indeed is useful to have them in the same public repository
(think of my git.git repository at k.org) for distribution purposes, it
does not mean that it is a good thing to create and manipulate these
unrelated histories in the same repository at all. These two branches
(and the same thing can be said for 'todo' branch) are never checked out
in a repository with an worktree that normally checks out the primary
branches (e.g. 'master', 'next', etc.) nowhere in my workflow for two very
simple reasons:
(1) doing so would disrupt the normal work done in the primary branches.
(2) updating them requires a separate checkout of the primary branch
anyway.
Growing these histories are done in separate repositories unrelated to the
primary project worktree; they are pushed into the same public repository
only for ease of cloning, for Documentation/install-doc-quick.sh script to
run a moral equivalent of "tar-tree | (cd elsewhere && tar xf -)".
And even the "ease-of-cloning" is merely a justfication after the fact.
The original and the only reason why these pregenerated documentation
branches are in the same distribution repository is because I only have
write privilege to /pub/scm/git/git.git/ at k.org, and not to the whole
/pub/scm/git/ hierarchy. Otherwise I may have published these unrelated
branches in their own repositories (e.g. /pub/scm/git/docs.git/) and made
install-doc-quick.sh use data from there; it might have avoided confusing
end users, perhaps.
It also might be useful to extend these pages with the "going open source?
here is how to use a 'mostly same paths' disconnected history to do so"
example from the discussion. That workflow I can see how it may make
sense to use "checkout --orphan" to create the new history in the same
repository.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html