Re: [PATCH 7/7] Documentation: git-init: flesh out example
On Wed, Aug 06, 2014 at 10:41:10AM -0700, Junio C Hamano wrote: 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 commit3 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 git. 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. Ah yes, I like the brevity. Actually, I would like to know if anything is special about the root-commit... 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. Thank you for the insight. I won't bother adding a blurb about root-commit and what it means because they are not that special, as you said so yourself. -- 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
Re: [PATCH 7/7] Documentation: git-init: flesh out example
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 commit3 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 git. 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 root-commit... 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
Re: [PATCH 7/7] Documentation: git-init: flesh out example
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 commit3 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? + -1 prepare /path/to/my/codebase/.git directory -2 add all existing file to the index +1 Create a /path/to/my/codebase/.git directory. +2 Add all existing files to the index. +3 Create the first root-commit. GIT --- -- 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
Re: [PATCH 7/7] Documentation: git-init: flesh out example
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 commit3 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 git. 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. Actually, I would like to know if anything is special about the root-commit (I only know it is written as such, with a hyphen, because that is what you get from git's output message). I am not sure if this root-commit idea is explained in detail in git's other documentation. + -1 prepare /path/to/my/codebase/.git directory -2 add all existing file to the index +1 Create a /path/to/my/codebase/.git directory. +2 Add all existing files to the index. +3 Create the first root-commit. GIT --- -- 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
[PATCH 7/7] Documentation: git-init: flesh out example
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 commit3 + -1 prepare /path/to/my/codebase/.git directory -2 add all existing file to the index +1 Create a /path/to/my/codebase/.git directory. +2 Add all existing files to the index. +3 Create the first root-commit. GIT --- -- 2.0.3 -- 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
