Development/Git/Configuration - Revision history

Roneygomes: Added a missing "be" between "to" and "formatted" in the first paragraph of the Commit Template section.

2013-03-19T13:59:23Z

Added a missing "be" between "to" and "formatted" in the first paragraph of the Commit Template section.

Jstaniek: /* Multiple Work Branches */

2012-06-18T19:53:43Z

‎Multiple Work Branches

Sreich: Add gitexcludes file documentation, now that I've added it to kdelibs master (well, frameworks branch apparently)

2011-12-27T05:29:45Z

Add gitexcludes file documentation, now that I've added it to kdelibs master (well, frameworks branch apparently)

Jstaniek: /* URL Renaming */

2011-07-29T21:18:17Z

‎URL Renaming

Hein: /* Basic Settings */

2011-06-26T18:21:23Z

‎Basic Settings

Hein: /* Basic Settings */ Add note about relationship to Bugzilla

2011-06-26T18:20:18Z

‎Basic Settings: Add note about relationship to Bugzilla

Odysseus: /* Multiple Work Branches */

2011-05-25T12:33:52Z

‎Multiple Work Branches

Odysseus: /* Multiple Work Branches */

2011-05-25T12:28:10Z

‎Multiple Work Branches

Odysseus: /* git-new-workdir */

2011-05-25T12:25:48Z

‎git-new-workdir

Odysseus: /* RSA Key fingerprint for git.kde.org */

2011-05-25T11:59:24Z

‎RSA Key fingerprint for git.kde.org

@@ Line 52: / Line 52: @@
 === Commit Template ===
-The Commit Template is a standard layout for commit messages, usually containing instructions for how a project expects messages to formatted and what details are to be included.  You can choose to set a User Level template as a default, then use any project level variations at a repo level.
+The Commit Template is a standard layout for commit messages, usually containing instructions for how a project expects messages to be formatted and what details are to be included.  You can choose to set a User Level template as a default, then use any project level variations at a repo level.
 It is recommended to use the kdelibs template as your default.  Once you have cloned kdelibs then set as follows to ensure you use the latest available version:

@@ Line 199: / Line 199: @@
 One solution would be to have a separate repository clone for each branch you wish to work on in parallel, but this takes up more disk space, the clones and branches can easily get out-of-sync, and it makes forward/back porting bug fixes between branches more difficult.  If choosing this method then you should make each new clone from your initial local clone rather than from the main repo as this will be quicker.
-The ideal solution is for a single git repository clone to provide separate source directories for each branch you wish to work on.  This can be achieved using the git-new-workdir script provided in the Git contrib directory.  This script uses sym-links to create what appears as a new clone in a separate folder but actually uses the same local clone.
+The ideal solution is for a single git repository clone to provide separate source directories for each branch you wish to work on, without performing full clone (what consumes disk space and requires fetching each clone separately). This can be achieved using the '''git-new-workdir''' script provided in the Git contrib directory.  This script uses symbolic links to create what appears as a new clone in a separate folder but actually uses the same local clone.
 The git-new-workdir script may be installed as part of your system git.  If not download the script from [https://github.com/git/git/raw/master/contrib/workdir/git-new-workdir the git repo] and install in your ~/.bin.

@@ Line 66: / Line 66: @@
   cd <repo>
   git config commit.template .commit-template
 === Push Default ===

@@ Line 85: / Line 85: @@
 Instead of having to remember and type in the different full git addresses for pulling and pushing, we recommend you manually add the following to your Git User Configuration (~/.gitconfig):
-  [url "git://anongit.kde.org/"]
+  <nowiki>[url "git://anongit.kde.org/"]</nowiki>
       insteadOf = kde:
   [url "git@git.kde.org:"]

@@ Line 44: / Line 44: @@
   git config --global user.email <Your identity.kde.org email>
-The name and email address you configure will be used as the author information for every commit you make. '''Note that in order for commit message keywords like BUG and CCBUG to work, your Bugzilla account email address has to match the email address used in your commits.'''
+The name and email address you configure will be used as the author information for every commit you make. Note that in order for commit message keywords such as BUG and CCBUG to work, your Bugzilla account email address has to match the email address used in your commits.
 To enable colored output when using git:

@@ Line 164: / Line 164: @@
 === Multiple Work Branches ===
-If you need to regularly work on two or more different branches (e.g. master and the most recent stable release) then you will find that switching between the branches can trigger a lot of rebuilding.
+You will often want to have more than one build environment in parallel, for example if you want to work on both stable and unstable branches at the same time.
-One solution is to have a separate clone of the repository for each branch you want to regularly work on, however this will use a lot of space and each clone will have to be kept up to date separately.  If choosing this method then you should make each new clone from your initial local clone rather than from the main repo as this will be quicker.
+With Git you can easily have many work branches in your repository and easily switch between them.  The problem here however is that you can only work on the one branch at a time, and switching branches will usually trigger a massive rebuild of the entire repository.
-A better solution is to use the git-new-workdir script from git contrib which uses sym-links to create what appears as a new clone in a separate folder but actually uses the same local clone.
+One solution would be to have a separate repository clone for each branch you wish to work on in parallel, but this takes up more disk space, the clones and branches can easily get out-of-sync, and it makes forward/back porting bug fixes between branches more difficult.  If choosing this method then you should make each new clone from your initial local clone rather than from the main repo as this will be quicker.
 The git-new-workdir script may be installed as part of your system git.  If not download the script from [https://github.com/git/git/raw/master/contrib/workdir/git-new-workdir the git repo] and install in your ~/.bin.

@@ Line 172: / Line 172: @@
 The git-new-workdir script may be installed as part of your system git.  If not download the script from [https://github.com/git/git/raw/master/contrib/workdir/git-new-workdir the git repo] and install in your ~/.bin.
-For example, assuming your have a kdelibs.git clone living in ~/kde/src/master/kdelibs, then the following command will create a 4.6 work branch in ~/kde/src/branches/4.6/kdelibs:
+For example, assuming your have a kdelibs.git clone living in ~/kde/src/master/kdelibs, then the following command will create a 4.6 work branch in ~/kde/src/4.6/kdelibs:
-  git-new-workdir ~/kde/src/master/kdelibs ~/kde/src/branches/4.6/kdelibs KDE/4.6
+  git-new-workdir ~/kde/src/master/kdelibs ~/kde/src/4.6/kdelibs KDE/4.6
 == RSA Key fingerprint for git.kde.org==
 c8:45:ba:89:85:11:78:b5:a4:09:d9:31:f6:7f:7c:79