<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title></title>
<link rel="stylesheet" media="screen" type="text/css" href="./style.css" />
<link rel="stylesheet" media="screen" type="text/css" href="./design.css" />
<link rel="stylesheet" media="print" type="text/css" href="./print.css" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<h1 class="sectionedit108"><a name="geda_gaf_uses_git" id="geda_gaf_uses_git">gEDA/gaf uses git</a></h1>
<div class="level1">
<p>
gEDA uses <strong>git</strong> for source code management. git is a distributed version control system, where every user has his or her own full copy of the revision history.
</p>
<ul>
<li class="level1"><div class="li"> <a href="http://git.or.cz/" class="urlextern" title="http://git.or.cz/" rel="nofollow">Official git website</a></div>
</li>
<li class="level1"><div class="li"> <a href="http://www.kernel.org/pub/software/scm/git/docs/" class="urlextern" title="http://www.kernel.org/pub/software/scm/git/docs/" rel="nofollow">git documentation online</a></div>
</li>
<li class="level1"><div class="li"> <a href="http://en.wikipedia.org/wiki/Git_(software)" class="interwiki iw_wp" title="http://en.wikipedia.org/wiki/Git_(software)">git Wikipedia page</a></div>
</li>
</ul>
</div>
<!-- EDIT108 SECTION "gEDA/gaf uses git" [1-372] -->
<h2 class="sectionedit109"><a name="installing_git_related_tools" id="installing_git_related_tools">Installing git & related tools</a></h2>
<div class="level2">
<p>
The core git tools are of course required for using the repository, and the documentation is always useful. However, other tools are often helpful for working with git:
</p>
<ul>
<li class="level1"><div class="li"> <a href="http://www.kernel.org/pub/software/scm/git/docs/gitk.html" class="urlextern" title="http://www.kernel.org/pub/software/scm/git/docs/gitk.html" rel="nofollow">gitk</a>, a visual history repository browser</div>
</li>
<li class="level1"><div class="li"> <a href="http://www.procode.org/stgit/" class="urlextern" title="http://www.procode.org/stgit/" rel="nofollow">Stacked Git</a>, for working with patchsets</div>
</li>
</ul>
<p>
Debian-based
</p>
<pre class="code">apt-get install git-core git-doc gitk stgit</pre>
<p>
you may also want:
</p>
<pre class="code">apt-get install git-email git-completion</pre>
<p>
Fedora Linux
</p>
<pre class="code">yum install git stgit</pre>
</div>
<!-- EDIT109 SECTION "Installing git & related tools" [373-943] -->
<h2 class="sectionedit110"><a name="learning_to_use_git" id="learning_to_use_git">Learning to use git</a></h2>
<div class="level2">
<p>
The toplevel documentation for git can be found at:
</p>
<p>
<a href="http://www.kernel.org/pub/software/scm/git/docs/" class="urlextern" title="http://www.kernel.org/pub/software/scm/git/docs/" rel="nofollow">Official git docs</a>
</p>
<p>
The user's manual for git can be found at:
</p>
<p>
<a href="http://www.kernel.org/pub/software/scm/git/docs/user-manual.html" class="urlextern" title="http://www.kernel.org/pub/software/scm/git/docs/user-manual.html" rel="nofollow">git user manual</a>
</p>
<p>
A current tutorial can be found at:
</p>
<p>
<a href="http://www.kernel.org/pub/software/scm/git/docs/gitcore-tutorial.html" class="urlextern" title="http://www.kernel.org/pub/software/scm/git/docs/gitcore-tutorial.html" rel="nofollow">git core tutorial</a>
</p>
<p>
Other nice tutorials/webpages:
</p>
<p>
<a href="http://wiki.sourcemage.org/Git_Guide" class="urlextern" title="http://wiki.sourcemage.org/Git_Guide" rel="nofollow">Git Guide</a><br/>
<a href="http://git.or.cz/course/index.html" class="urlextern" title="http://git.or.cz/course/index.html" rel="nofollow">git Crash Courses</a><br/>
</p>
<p>
Keep in mind that some of these tutorials are a little dated and may not cover current git syntax.
</p>
</div>
<!-- EDIT110 SECTION "Learning to use git" [944-1613] -->
<h2 class="sectionedit111"><a name="accessing_the_repository_anonymously" id="accessing_the_repository_anonymously">Accessing the repository anonymously</a></h2>
<div class="level2">
<p>
To clone the geda-gaf.git repository (or any repository hosted at <a href="http://git.geda-project.org" class="urlextern" title="http://git.geda-project.org" rel="nofollow">git.geda-project.org</a>) using anonymous git access:
</p>
<pre class="code">git clone git://git.geda-project.org/geda-gaf.git</pre>
<p>
or
</p>
<pre class="code">git clone git://git.geda-project.org/pcb.git</pre>
<p>
For different repositories hosted at git.geda-project.org, just substitute the last part of the above <acronym title="Uniform Resource Locator">URL</acronym>.
</p>
<p>
There is a <a href="http://hjemli.net/git/cgit/about/" class="urlextern" title="http://hjemli.net/git/cgit/about/" rel="nofollow">cgit</a> interface to the repositories of the various projects. Just point a www browser to <a href="http://git.geda-project.org/" class="urlextern" title="http://git.geda-project.org/" rel="nofollow">http://git.geda-project.org/</a> .
</p>
</div>
<!-- EDIT111 SECTION "Accessing the repository anonymously" [1614-2197] -->
<h2 class="sectionedit112"><a name="accessing_the_repository_with_write_permission" id="accessing_the_repository_with_write_permission">Accessing the repository with write permission</a></h2>
<div class="level2">
<p>
For developer git access, you should contact DJ Delorie to get your <acronym title="Secure Shell">SSH</acronym> public key installed; having done so, the git <acronym title="Uniform Resource Locator">URL</acronym> to push to is:
</p>
<pre class="code">ssh://git@git.geda-project.org/geda-gaf.git</pre>
<p>
or
</p>
<pre class="code">ssh://git@git.geda-project.org/pcb.git</pre>
<p>
You will also need to edit your ~/.ssh/config file (create it if it doesn't exist) and put the following text into it:
</p>
<pre class="code">Host git.geda-project.org
Port 65</pre>
<p>
Note: If you're having trouble pushing commits upstream, make sure you're using
git 1.5 or newer.
</p>
</div>
<!-- EDIT112 SECTION "Accessing the repository with write permission" [2198-2746] -->
<h2 class="sectionedit113"><a name="making_and_committing_changes" id="making_and_committing_changes">Making and committing changes</a></h2>
<div class="level2">
</div>
<!-- EDIT113 SECTION "Making and committing changes" [2747-2790] -->
<h3 class="sectionedit114"><a name="setting_up_user_information" id="setting_up_user_information">Setting up user information</a></h3>
<div class="level3">
<p>
You should make sure that your username & e-mail address are set in your git configuration file.
</p>
<pre class="code">$ git config --global user.name "Your Name Comes Here"
$ git config --global user.email you@yourdomain.example.com</pre>
</div>
<!-- EDIT114 SECTION "Setting up user information" [2791-3049] -->
<h3 class="sectionedit115"><a name="committing_patches_from_other_contributors" id="committing_patches_from_other_contributors">Committing patches from other contributors</a></h3>
<div class="level3">
<p>
If you apply a patch from someone else (e.g. from a launchpad patch record) there are a few things to consider.
Git stores two different names and e-mail addresses for a given commit: the “author” of the patch, and the “committer” of the patch, so these details must be set correctly when making the commit.
</p>
<p>
First of all, check a few things:
</p>
<ul>
<li class="level1"><div class="li"> You have the latest version of the patch.</div>
</li>
<li class="level1"><div class="li"> The author of the patch is happy for it to be committed (and wasn't still working on it)</div>
</li>
<li class="level1"><div class="li"> That the you're happy with the patch, and taking responsibility for committing those changes.</div>
</li>
</ul>
<p>
For simplicity, start from an unmodified up-to date tree (git status shows no changes).
</p>
<p>
Apply the patch as usual (as an example):
</p>
<pre class="code">$ patch -p1 < example_changes.patch</pre>
<p>
You can also use the git apply command:
</p>
<pre class="code">$ git apply example_changes.patch</pre>
<p>
If the patch needs any minor editing before it is committed (eg. white-space changes), please inform the author this was done.
They may have other work based on their patch and will want to know if there were changes to the applied version.
</p>
<p>
Note: <em>This is easy to miss accidentally if your editor introduces tabs. Please avoid letting it do so!</em>
</p>
<p>
For every file changed, added or removed, you need to inform git before it will commit the changes. To see the modified files, run:
</p>
<pre class="code">$ git status</pre>
<p>
For speed, the command:
</p>
<pre class="code">$ git add -u</pre>
<p>
will update all files which git tracks, including any files which were deleted.
</p>
<p>
For adding any new files the patch introduced, use the command
</p>
<pre class="code">$ git add new_file.c</pre>
<p>
Note: git add also takes wild-cards.
</p>
<p>
Commit the patch, making sure that the Author's name and e-mail address are specified:
</p>
<pre class="code">$ git commit --author "Author's Name Comes Here <author@example.com>"</pre>
<p>
As an alternative, you can set the GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL environment variables before issuing the normal commit command
</p>
</div>
<!-- EDIT115 SECTION "Committing patches from other contributors" [3050-4978] -->
<h3 class="sectionedit116"><a name="writing_good_commit_message" id="writing_good_commit_message">Writing good commit message</a></h3>
<div class="level3">
<p>
The commit message format is as follows: a *strictly* one-line summary of the patch, followed by a blank line, followed by a long description. If you can fit the whole description of the patch on one line, that's fine; don't bother with the long description.
</p>
<p>
The one-line summary is used for generating e-mail subject lines, and for the gitk & gitweb log displays. Having a good one-line summary is really useful, because it means those tools can be used to quickly find a commit of interest.
</p>
<p>
<strong>Do not</strong> put a list of files changed into commit messages. This information can be trivially obtained using the git tools.
</p>
<p>
Example:
</p>
<pre class="code">Added new GedaList class derived from GObject
This abstracts a GList with API for write access. Its main use is in list
change notification, as it emits a "changed" g_signal when modified.
Read only access to the underlying GList is provided by an accessor,
currenly implemented as a macro.</pre>
</div>
<!-- EDIT116 SECTION "Writing good commit message" [4979-5960] -->
<h3 class="sectionedit117"><a name="push_is_destructive" id="push_is_destructive">Push is Destructive</a></h3>
<div class="level3">
<p>
<strong>Warning: pushing changes to the remote repository is destructive</strong>
</p>
<p>
Unlike <acronym title="Concurrent Versions System">CVS</acronym>, it is not the committing of changes which changes the master repository, but pushing changes using git-push. You should always double- (or triple-) check that the commits you are about to push are actually meant for the main repository.
</p>
</div>
<!-- EDIT117 SECTION "Push is Destructive" [5961-6314] -->
<h2 class="sectionedit118"><a name="how_do_i" id="how_do_i">How Do I ... ?</a></h2>
<div class="level2">
<p>
For a more information please checkout the <a href="http://wiki.sourcemage.org/Git_Guide" class="urlextern" title="http://wiki.sourcemage.org/Git_Guide" rel="nofollow">Git Guide</a>.
</p>
</div>
<!-- EDIT118 SECTION "How Do I ... ?" [6315-6438] -->
<h3 class="sectionedit119"><a name="get_a_copy_of_geda_gaf_git_repository" id="get_a_copy_of_geda_gaf_git_repository">... get a copy of gEDA/gaf git repository?</a></h3>
<div class="level3">
<p>
For anonymous read-only access:
</p>
<pre class="code">$ git clone git://git.geda-project.org/geda-gaf</pre>
<p>
For developers with read/write access:
</p>
<pre class="code">$ git clone ssh://git@git.geda-project.org/geda-gaf</pre>
</div>
<!-- EDIT119 SECTION "... get a copy of gEDA/gaf git repository?" [6439-6671] -->
<h3 class="sectionedit120"><a name="keep_my_local_copy_current" id="keep_my_local_copy_current">... keep my local copy current?</a></h3>
<div class="level3">
<p>
For those who are are not merging changes back into the central git repository you can run:
</p>
<pre class="code">$ git pull</pre>
<p>
However, for those of you who are going to be pushing your changes back into the central git repository, using git pull will clutter up the history with merge messages (“Merge branch 'master'”). To avoid this you should run:
</p>
<pre class="code">$ git fetch
$ git rebase origin</pre>
</div>
<!-- EDIT120 SECTION "... keep my local copy current?" [6672-7086] -->
<h3 class="sectionedit121"><a name="commit_my_changes_to_the_local_git_repository" id="commit_my_changes_to_the_local_git_repository">... commit my changes to the local git repository?</a></h3>
<div class="level3">
<pre class="code">$ git commit -a</pre>
<p>
This command will find all changed files that git knows about (added with git-add) and prompt you for a commit message. Be sure to follow the above commit message convention if you plan on pushing your changes to the central repository.
</p>
<p>
If you want to commit files in the current directory or want to explicitly commit only certain files, do not specify the -a flag and/or specify the individual filenames on the command line like:
</p>
<pre class="code">$ git commit filename1 filename2</pre>
</div>
<!-- EDIT121 SECTION "... commit my changes to the local git repository?" [7087-7640] -->
<h3 class="sectionedit122"><a name="undo_any_uncommitted_local_changes" id="undo_any_uncommitted_local_changes">... undo any uncommitted local changes?</a></h3>
<div class="level3">
<pre class="code">$ git checkout -f</pre>
<p>
Note this will discard any changes to any files that are being tracked by git.
</p>
<p>
If you want to just discard edits in a single file, just run:
</p>
<pre class="code">$ git checkout path/to/file/to/discard</pre>
<p>
If you want to discard all edits from the current directory and downward recursively, just run:
</p>
<pre class="code">$ git checkout .</pre>
</div>
<!-- EDIT122 SECTION "... undo any uncommitted local changes?" [7641-8016] -->
<h3 class="sectionedit123"><a name="fix_change_my_last_commit" id="fix_change_my_last_commit">... fix/change my last commit?</a></h3>
<div class="level3">
<pre class="code">$ Edit whatever files
$ git commit --amend filename1..filenameN</pre>
<p>
This will pickup any changes you made and recommit them again with the previous commit message.
</p>
</div>
<!-- EDIT123 SECTION "... fix/change my last commit?" [8017-8224] -->
<h3 class="sectionedit124"><a name="track_a_branch" id="track_a_branch">... track a branch?</a></h3>
<div class="level3">
<pre class="code">$ git checkout --track -b <local name> origin/<remote name></pre>
<p>
This will create a branch with the <local name> which tracks the <remote name>'d branch.
</p>
</div>
<!-- EDIT124 SECTION "... track a branch?" [8225-8408] -->
<h3 class="sectionedit125"><a name="create_a_branch_starting_at_a_tag" id="create_a_branch_starting_at_a_tag">... create a branch (starting at a tag)?</a></h3>
<div class="level3">
<p>
Run the following commands (using the stable-1.4 branch as an example):
</p>
<pre class="code"> $ git branch stable-1.4 1.4.0-20080127
$ git checkout stable-1.4
<make changes>
$ git commit -a</pre>
<p>
To publish this branch in the central repository (requires write access to the central repository):
</p>
<pre class="code"> $ git push origin stable-1.4</pre>
</div>
<!-- EDIT125 SECTION "... create a branch (starting at a tag)?" [8409-8776] -->
<h3 class="sectionedit126"><a name="fetch_a_development_branch_from_other_people" id="fetch_a_development_branch_from_other_people">... fetch a development branch from other people?</a></h3>
<div class="level3">
<p>
Beside the <a href="http://git.geda-project.org/" class="urlextern" title="http://git.geda-project.org/" rel="nofollow">http://git.geda-project.org/</a> repository we have a mirror of that repository at <a href="http://repo.or.cz/w/geda-gaf.git" class="urlextern" title="http://repo.or.cz/w/geda-gaf.git" rel="nofollow">http://repo.or.cz/w/geda-gaf.git</a>. Some of the developers have forks of that repository with new feature branches.
</p>
<p>
If you like to test one of the feature branches you have to fetch it from their repository.
The easiest way to get a branch is to use the fetch command.
</p>
<pre class="code"> $ git fetch repository_url remote_branchname:local_branchname</pre>
<p>
<strong>Examples:</strong>
Getting the <em>cairo_experiment</em> branch from Peter C. would look like this:
</p>
<pre class="code"> $ git fetch git://repo.or.cz/geda-gaf/pcjc2.git cairo_experiment:peters_cairo_experiment</pre>
<p>
Now you can switch to the local copy of the branch <em>peters_cairo_experiment</em> and play with it.
</p>
<p>
It is also possible to add multiple remote forks into the local repository:
</p>
<pre class="code"> $ git remote add <name> <url>
$ git fetch <name></pre>
<p>
As long as <name> is unique you will be able to follow their work without the
need to create local branches. With a tool like gitk it is now possible to keep
an eye on development in various feature branches on various forks:
</p>
<pre class="code"> $ gitk --all</pre>
<p>
<strong>Examples:</strong>
</p>
<pre class="code"> $ git remote add peter-b https://github.com/peter-b/geda-gaf.git
$ git fetch peter-b
$ git remote add gareth8118 https://github.com/gareth8118/geda-gaf.git
$ git fetch gareth8118
$ git remote add bert https://github.com/bert/geda-gaf.git
$ git fetch bert
$ gitk --all</pre>
<p>
Now gitk can become quite filled up, but <strong>File</strong>→<strong>List references</strong> (<kbd>F2</kbd>) will open
a dialog for easier navigation.
</p>
<p>
Updating favourite remotes will then boil down to:
</p>
<pre class="code"> $ git fetch --all</pre>
</div>
<!-- EDIT126 SECTION "... fetch a development branch from other people?" [8777-10444] -->
<h3 class="sectionedit127"><a name="format_a_patch_to_send_to_the_developers" id="format_a_patch_to_send_to_the_developers">... format a patch to send to the developers?</a></h3>
<div class="level3">
<p>
The simplest possible way includes all changes since the local repository was syncronized with the repository at geda-project.org:
</p>
<pre class="code">$ git diff > name_of_patchfile</pre>
<p>
A more complicated way with more control on what the patch contains:
</p>
<pre class="code">$ git add -i # select files to be committed
$ git status # check you're committing what you think you're committing
$ git commit # create a commit
$ git format-patch -1 # create a patch file based on that commit</pre>
<p>
This will output a filename which contains the patch. Be sure to look at the documentation for format-patch for more information. This file can be e-mailed to developers who have write access and can be applied using git apply.
</p>
</div>
<!-- EDIT127 SECTION "... format a patch to send to the developers?" [10445-11216] -->
<h3 class="sectionedit128"><a name="recover_from_a_really_messed_up_local_repository" id="recover_from_a_really_messed_up_local_repository">... recover from a really messed up local repository?</a></h3>
<div class="level3">
<p>
First off, do not push any repository that you think is somehow messed up. Ask one of the experienced git people first.
</p>
<p>
Second, the command that will really save your bacon is git-reflog. Using it works something like this:
</p>
<pre class="code"> $ git reflog
086908e... HEAD@{0}: cherry-pick: Last minute updates to the READMEs for all pro
2a79a23... HEAD@{1}: checkout: moving to master
2a79a23... HEAD@{2}: checkout: moving to master
...
$ git reset --hard HEAD@{1}</pre>
<p>
The last command (git reset --hard ...) will rollback all your changes to the “checkout: moving to master”. Remember: don't panic! Most things are fixable when using git.
</p>
</div>
<!-- EDIT128 SECTION "... recover from a really messed up local repository?" [11217-] --></body>
</html>
distrib
>
Mageia
>
5
>
x86_64
>
media
>
core-release
>
by-pkgid
>
f2f28f61487f3042d93877451f0a311f
>
files
>
225
