Linus Arver <linusar...@gmail.com> writes:
> On Tue, Aug 05, 2014 at 03:14:48PM -0700, Junio C Hamano wrote:
>> Linus Arver <linusar...@gmail.com> writes:
>> > Signed-off-by: Linus Arver <linusar...@gmail.com>
>> > ---
>> > Documentation/git-init.txt | 6 ++++--
>> > 1 file changed, 4 insertions(+), 2 deletions(-)
>> > diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
>> > index b94d165..16e9f9c 100644
>> > --- a/Documentation/git-init.txt
>> > +++ b/Documentation/git-init.txt
>> > @@ -138,10 +138,12 @@ Start a new Git repository for an existing code
>> > base::
>> > $ cd /path/to/my/codebase
>> > $ git init <1>
>> > $ git add . <2>
>> > +$ git commit <3>
>> I agree it is a good discipline to make the initial "pristine"
>> import immediately after "git add ." without doing anything else.
>> Perhaps the description below wants to make it more explicit?
> I could add a comment like the following:
> For new repositories, creating a commit immediately after "git add
> ." is good practice as it will cleanly separate any preexisting work
> (done under some other VCS, for example) from any new work done with
> Does this make sense? I am not sure how explicit you want it to be, or
> whether I captured what you wanted to be explained.
I was thinking more along the lines of
<3> Record the pristine state as the first commit in the history.
which should suffice without becoming excessively verbose.
> Actually, I would like to know if anything is special about the
As far as Git is concerned, they are just ordinary commits without
any parents. A commit in Git can have zero or more parents, so from
that "structural" point of view, they are not that special.
They are considered special by users because they represent the
beginning of the project history.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html