Difference between revisions of "Git"

From GnuCash
Jump to: navigation, search
(Git - Add back first 2 sections accidentally deleted in last edit)
(Resolving Merge Conflicts: Do not confuse -a = --all with --amend)
(12 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
= What is Git? =
 
= What is Git? =
+
 
 
[http://git-scm.com/ Git] is a ''[https://en.wikipedia.org/wiki/Distributed_version_control distributed]'' '''[https://en.wikipedia.org/wiki/Version_control version control system]''' (VCS) originally developed by Linus Torvalds for managing Linux source code without requiring a central server. It is also the primary VCS used by the [http://www.gnome.org Gnome] and [http://www.freedesktop.org Free Desktop] projects. You can get the latest version for your system and read a rich variety of online documentation at [http://git-scm.com/ Git's Home]. In particular, ''Pro Git'' by Scott Chacon is available in several languages for free online reading at [http://git-scm.com/book Git Book], where you can also download the English version as a PDF, ebook, or mobi.
 
[http://git-scm.com/ Git] is a ''[https://en.wikipedia.org/wiki/Distributed_version_control distributed]'' '''[https://en.wikipedia.org/wiki/Version_control version control system]''' (VCS) originally developed by Linus Torvalds for managing Linux source code without requiring a central server. It is also the primary VCS used by the [http://www.gnome.org Gnome] and [http://www.freedesktop.org Free Desktop] projects. You can get the latest version for your system and read a rich variety of online documentation at [http://git-scm.com/ Git's Home]. In particular, ''Pro Git'' by Scott Chacon is available in several languages for free online reading at [http://git-scm.com/book Git Book], where you can also download the English version as a PDF, ebook, or mobi.
  
If you know nothing about version control, that doesn't matter. Just read [http://git-scm.com/book/en/v2/Getting-Started-About-Version-Control Getting Started - About Version Control]. There in the left column you can select your language.
+
If you know nothing about version control, that doesn't matter. Just read [http://git-scm.com/book/en/v2/Getting-Started-About-Version-Control Getting Started - About Version Control]. There in the left column you can select your language.  
  
 
Another good place to start is [https://help.github.com/articles/good-resources-for-learning-git-and-github/ Good Resources for Learning Git and GitHub] - not only if you want to use GitHub for [[#Pull Requests]].
 
Another good place to start is [https://help.github.com/articles/good-resources-for-learning-git-and-github/ Good Resources for Learning Git and GitHub] - not only if you want to use GitHub for [[#Pull Requests]].
  
  git help
+
git help
 
will give you a list of usual commands and
 
will give you a list of usual commands and
 
  git help <command>
 
  git help <command>
Line 17: Line 17:
 
* [http://www.sourcetreeapp.com/ SourceTree] for Windows or Mac
 
* [http://www.sourcetreeapp.com/ SourceTree] for Windows or Mac
 
and most IDEs have plugins for it.
 
and most IDEs have plugins for it.
 +
 
= What has that to do with Gnucash? =
 
= What has that to do with Gnucash? =
We have converted from Subversion to Git in order to take advantage of its ''branching'' and ''merging'' facilities, which are much richer than those provided by Subversion.
+
 
 +
We are using Git to manage our code and documentation sources.
  
 
Our '''public repositories''' are ''mirrored on Github'': for [https://github.com/Gnucash/gnucash code], [https://github.com/Gnucash/gnucash-docs documentation] and for the [https://github.com/Gnucash/gnucash-htdocs website]. These are updated from the ''primary repository'' by commit hooks, so barring technical problems changes appear in these repositories within a few seconds of being committed to the primary.
 
Our '''public repositories''' are ''mirrored on Github'': for [https://github.com/Gnucash/gnucash code], [https://github.com/Gnucash/gnucash-docs documentation] and for the [https://github.com/Gnucash/gnucash-htdocs website]. These are updated from the ''primary repository'' by commit hooks, so barring technical problems changes appear in these repositories within a few seconds of being committed to the primary.
  
<tt>svn.gnucash.org</tt> is just another name for <tt>code.gnucash.org</tt>, the server that hosts the '''canonical git repository''', wiki, [[Mailing Lists]], automated win32 builds, and the nightly builds  of the [http://code.gnucash.org/docs/ documentation and API docs] (via [[Doxygen]]) for both [[#Branchs|branchs]]. The old SVN repository is there too and it is possible to check out from it but since it doesn't take commits there's no reason to do so.
+
<tt>code.gnucash.org</tt> is the server that hosts the '''canonical git repository''', wiki, [[Mailing Lists]], automated win32 builds, and the nightly builds  of the [http://code.gnucash.org/docs/ documentation and API docs] (via [[Doxygen]]) for both [[#Branches|branches]].
  
 
= Using the Github Repository =
 
= Using the Github Repository =
 
== Branches ==
 
There are are 2 important branches in most of our repositories:
 
:;master: is the default branch in git. ''New features'' and their documentation should be based on this branch. In the old svn days this was <tt>trunk</tt>. For convenience for users migrating from svn a ''trunk'' branch has been set up as an alias for the master branch but you are encouraged to switch to master as your main branch.
 
:;maint: ''Bugfixes'', ''translations'', improvements of the ''documentation'' should usually be applied on this branch.
 
 
Non-Committers should always work in a branch specific to the bug or feature being worked on, not the master or maint branch. Name the feature or working branch after the bug or feature - e.g. bug-12345 or invoice-new-button.
 
  
 
== Non-Committers ==
 
== Non-Committers ==
There are 2 main ways to submit bug fixes, modifications or enhancements for review:
 
  
:;GitHub pull requests: These are preferred by the developers due to rich GitHub code review functionality.
+
If you are new to using git, you may find it useful to read [[Git_For_Newbies|Git For Newbies]] for more information about specific git commands and how they are used in the process of modifying GnuCash.
  
::Proceed to [[#Pull Requests]].
+
=== Set-Up ===
 +
Just clone the repository as usual:
  
:;Patches: A patch is essentially a specially formatted file containing a list of the files that have been changed, and for each file, before and after listings of the changed lines.
+
  git clone https://github.com/Gnucash/gnucash.git
 +
:;other URLs: https://github.com/Gnucash/gnucash-docs (documentation)
 +
::https://github.com/Gnucash/gnucash-htdocs (website)
 +
::See https://github.com/Gnucash for further repos e.g. with OS/distro specific build scripts.
  
=== Patches ===
+
==== Branches ====
 +
There are 2 important branches in most of our repositories:
 +
:;master: is the default branch in git. ''New features'' and their documentation should be based on this branch.
 +
:;maint: ''Bugfixes'', ''translations'', improvements of the ''documentation'' should usually be applied on this branch.
  
==== Patches - Set-Up ====
+
In your ''local working dir'' you should checkout one of them, e.g.:
 +
git checkout master
  
Create the directory you wish to hold your repository or repositories in and make it current.
+
When you have patches in master, use
Assuming you wish it to be called github in your home directory:
 
  mkdir ~/github
 
  cd ~/github
 
  
Create a copy of the required repository on your PC by cloning:
+
  git format-patch origin/master..master
  
  git clone https://github.com/Gnucash/gnucash.git
+
(or <tt>git diff</tt>) in the root directory of your local repository to prepare them; then add the patchfile as an attachment to the appropriate bug report.
:;other URLs: https://github.com/Gnucash/gnucash-docs.git (documentation)
 
::https://github.com/Gnucash/gnucash-htdocs.git (website)
 
::See https://github.com/Gnucash for further repos e.g. with OS/distro specific build scripts.
 
  
The clone example above will create the local repository
+
==== GitHub ====
  ~/github/gnucash
+
If you have a Github account, you could as well
and also defines a ''remote'' named ''origin'' pointing to the ''cloned from'' repository which you can use in future as a shortcut instead of the full URL.
+
# use Github's '''fork''' feature to set up a '''clone''' on GitHub. And then
 +
# clone from that repository instead (note that this is your personal ''read-write enabled'' clone):
 +
#: <pre>git clone git@github.com:<YOUR-GITHUB-USERNAME>/gnucash.git</pre>
 +
#: Note that this clone command takes the ''URL in a different format''.
 +
# With this form you will be able to push your local changes to your GitHub account as usual:
 +
#: <pre>git push origin master</pre>
  
Change into the repository directory:
+
{|cellpadding="20"
  cd gnucash
+
| Depending on your access rights you might continue with ...
 +
||[[#Pull Requests]]
 +
||[[#Committers]]
 +
|}
  
Only the default branch master will have been cloned.
+
=== Patches ===
If you wish to work on a modification to the maint branch, create local branch maint to track your remote branch:
+
If you're going to be submitting patches:
  git branch --track maint origin/maint
+
* Create a branch to work in:
 
+
** '''Bug fixes''' should branch off of ''maint'' unless the bug applies only to the unstable version.
==== Patches - Create a working-branch ====
+
** '''New features''' must branch off of ''master''.
* Open a bug in Bugzilla to attach your patch to if one doesn't already exist.
+
The following example is for a new feature; ''substitute <tt>maint</tt> for <tt>master</tt> if you're doing a bug-fix''.
 
* Use a particular working branch for ''only one'' bug or feature. This will make it much easier to make changes and generate new patches should that prove necessary.
 
* Use a particular working branch for ''only one'' bug or feature. This will make it much easier to make changes and generate new patches should that prove necessary.
* Create a local (on your PC) branch to work in:
 
:: '''Bug fixes''' should branch from ''maint'' unless the bug applies only to the unstable version.
 
:: '''New features''' must branch from ''master''.
 
The following example is for a new feature; ''substitute <tt>maint</tt> for <tt>master</tt> if you're doing a bug-fix''.
 
 
Checkout the required branch to create the working-branch from (master or maint), e.g.:
 
 
   git checkout master
 
   git checkout master
 
+
   git branch working-branch
Note: checkout prepares your local repository ready for work on a particular branch by resetting all files back to how they were at the time they were last committed.
+
* Rebase your working branch onto the target branch often so that you stay in sync:
It is much easier if you only checkout a branch after committing all changes you have made to the current branch.
 
You will get a warning if you try to change branches and there are uncommitted changes.
 
It is not wise to leave a file open in an editor while checking out a branch as you may accidentally save a version from another branch.
 
 
 
   git branch working-branch        # Creates branch ''working-branch'' from the current branch
 
  git checkout working-branch   # make working-branch current
 
 
 
You are now ready to make and test your changes in your local working branch.
 
 
 
==== Patches - Commit ====
 
See http://wiki.gnucash.org/wiki/Documentation_Update_Instructions#Step_11_Commit_your_Changes
 
 
 
==== Patches - Sync your local master/maint from origin ====
 
After you have completed your changes, to minimize the chances of your future patch conflicting with any changes that may have been committed
 
to the official GnuCash repositories while you were working:
 
 
 
* Update the local master or maint branch (depending on which your working branch was created from) in your local repository from origin:
 
  git pull origin master
 
* Rebase your working branch commits based on the updated master or maint:
 
 
   git rebase master working-branch
 
   git rebase master working-branch
 
+
* Open a bug in Bugzilla to attach your patch to if one doesn't already exist.
You can update both master and maint if you wish but you only need to update the branch on which your working branch was based.
+
* Write good commit messages in which the bug number and summary are the first line. Skip one line, then describe the patch. For example:
 
+
  [Bug 673193] - Possible Register migration to TreeView
* Test again to make sure everthing works with the rebased code
+
 
 
+
  Update the old register rewrite branch to work with the currently-released Gtk2.
==== Patches - Create Patch(es) ====
 
A patch file is created for each commit.
 
 
* Use <tt>git rebase -i</tt> as necessary to make a clean series of patches for complex changes.
 
* Use <tt>git rebase -i</tt> as necessary to make a clean series of patches for complex changes.
 +
* Be sure to do a fresh rebase from the target branch and a make check to ensure that everything works
 
* Use <tt>git format-patch</tt> to create the actual patches from your commits:
 
* Use <tt>git format-patch</tt> to create the actual patches from your commits:
   cd ~/github/gncucash
+
   git rebase master working-branch
   git format-patch origin/master..master
+
   git format-patch master
 
+
* Attach the resulting patch(es) to the bug report.
(or <tt>git diff</tt>) to prepare them.
 
 
 
* Attach the resulting patch(es) to the bug report. It is not necessary to email anyone as the relevant people are automatically emailed when you attach a patch to a bug.
 
 
* If a committer asks you to make changes, revise your original commit and make a new patch. Don't submit a patch to be applied on top of an old one. <tt>[https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html git-rebase] -i</tt> can be very helpful if you have a series of patches.
 
* If a committer asks you to make changes, revise your original commit and make a new patch. Don't submit a patch to be applied on top of an old one. <tt>[https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html git-rebase] -i</tt> can be very helpful if you have a series of patches.
* Once the patch has been either merged or rejected, you can delete the local working branch:
 
  git checkout master
 
  git branch -D working-branch
 
  E.g.
 
  git branch -D bug-99999 # delete local branch bug-99999
 
  
 
=== Pull Requests ===
 
=== Pull Requests ===
 
If you prefer, you can use a GitHub Pull Request instead of attaching a patch to a bug.
 
If you prefer, you can use a GitHub Pull Request instead of attaching a patch to a bug.
You'll need to create a GitHub account if you haven't got one already and set it up for ssh access.
+
* Fork the Gnucash/gnucash or Gnucash/gnucash-docs repo on GitHub. You'll need to create a GitHub account if you haven't got one already and set it up for ssh access. In the example below, we'll assume a GitHub userid of "Me". Substitute your real id.
 
+
* Add that branch as a remote in your local repository and push your working branch to it:
'''Suggested remote repository names for Non-Committers Using Pull Requests'''
+
  git remote add github ssh://git@github.com/Me/gnucash
 
+
   git branch -u github working-branch
Use the following names in your local PC repository for remote repositories:
+
* Perhaps an easier approach is to replace the push url:
 
+
   git remote set-url --push origin git@github.com/Me/gnucash
:'''upstream''': The official repository to which only authorized developers can write. E.g.
+
   git branch working-branch
::<tt>github.com/Gnucash/gnucash
+
* apply your ammendments and
::or
+
   git push
::github.com/Gnucash/gnucash-docs</tt>
+
* Now log in to your GitHub account, go to your forked gnucash repository, select <tt>working-branch</tt> from the pick list, and click ''pull request''. It's above the "last commit" line on the right in the directory view.
::These are actually public mirrors for the real GnuCash official repositories.
+
* In the resulting form, give your pull request a title and describe its motivation. If it's associated with a bug, use the bug number and title for your title and paste the bug URL into the description. Note that GitHub descriptions use Markdown and that there's a preview tab to help you make sure that everything looks the way you want it.
 
 
:'''origin''': This is your personal writable GitHub repository. E.g.
 
::<tt>github.com/[YOUR-GITHUB-USERNAME]/gnucash
 
::or
 
::github.com/[YOUR-GITHUB-USERNAME]/gnucash-docs</tt>
 
::Pull requests are made from here to the ''upstream'' repository.
 
 
 
==== Pull Requests - Set-Up Your Personal GitHub Repository ====
 
Use Github's '''fork''' feature to set up a your own personal read-write enabled '''clone''' on GitHub:
 
 
 
In a web browser, go to https://www.github.com, login and search for '''Gnucash'''.
 
Click on the link for the required repository, E.g.
 
  Gnucash/gnucash or Gnucash/gnucash-docs
 
Click on the Fork button at top right.
 
This will create
 
  www.github.com/[YOUR-GITHUB-USERNAME]/gnucash-docs
 
 
 
==== Pull Requests - Set-Up a Local Repository on your PC ====
 
As you will eventually push your modified local repository branch back to your personal GitHub repository, it is useful to
 
create your local PC repository by cloning from your personal GitHub repository, rather than the official
 
GnuCash repository. The remote name '''origin''' in your local repository, is automatically set up to point to where you clone from (I.e. your personal GitHub repository).
 
 
 
Create the directory you wish to hold your repository or repositories in and make it current.
 
Assuming you wish it to be called github in your home directory:
 
  mkdir ~/github
 
  cd ~/github
 
 
 
Clone from your remote personal repository ''origin'':
 
  git clone git@github.com:<YOUR-GITHUB-USERNAME>/gnucash.git</tt>
 
 
 
The clone example above will create the local repository
 
  ~/github/gnucash
 
and also defines a ''remote'' named ''origin'' pointing to the ''cloned from'' repository which you can use in future as a shortcut instead of the full URL.
 
 
 
Change into the repository directory:
 
  cd gnucash
 
 
 
Only the default branch master will have been cloned.
 
If you wish to work on a modification which should be applied to the maint branch, create local branch maint to track your remote branch:
 
   git branch --track maint origin/maint
 
 
 
==== Pull Requests - Create a working-branch ====
 
* Create a branch to work in:
 
:: '''Bug fixes''' should branch from ''maint'' unless the bug applies only to the unstable version.
 
:: '''New features''' must branch from ''master''.
 
* Open a bug in Bugzilla to enable your work to be tracked if one doesn't already exist.
 
 
 
The following example is for a new feature and therefore uses master; ''substitute <tt>maint</tt> for <tt>master</tt> if you're doing a bug-fix''.
 
* Use a particular working branch for ''only one'' bug or feature. This will make it much easier to make changes and generate new patches should that prove necessary.
 
  git checkout master
 
  git branch working-branch        # Create branch ''working-branch'' from the current branch
 
  git checkout working-branch
 
 
 
Note: ''checkout'' prepares your local repository for work on a particular branch by resetting all files back to how they were at the time that branch was last committed.
 
It is much easier if you only checkout a branch after committing all changes you have made to the current branch.
 
It is not wise to leave a file open in an editor while checking out a branch as you may accidentally save a version from another branch.
 
 
 
You are now ready to make and test your changes in your local working branch.
 
 
 
==== Pull Requests - Commit ====
 
See http://wiki.gnucash.org/wiki/Documentation_Update_Instructions#Step_11_Commit_your_Changes
 
 
 
==== Pull Requests - Sync your local master/maint from origin ====
 
After you have completed and tested your changes, to minimize the chances of your future pull request conflicting with any changes that may have been committed
 
to the official GnuCash repositories while you were working:
 
 
 
* Update the local master or maint branch (depending on which your working branch is based) in your local repository from origin:
 
   git pull origin master
 
* Rebase your working branch commits based on the updated master or maint:
 
  git rebase master working-branch
 
* Test again to make sure everything works with the rebased code.
 
 
 
You can update both master and maint if you wish but you only need to update the branch on which your working branch was based.
 
 
 
==== Pull Requests - Push Back to Personal Repository ====
 
If you followed these instructions and cloned to your local working-branch from your personal
 
github repository, then the remote name '''origin''' already points to your personal remote github
 
repository. Check your defined remotes by:
 
  git remote -v
 
The output of the above should include:
 
  origin git@github.com:<YOUR-GITHUB-USERNAME>/gnucash-docs.git (fetch)
 
   origin git@github.com:<YOUR-GITHUB-USERNAME>/gnucash-docs.git (push)
 
so you can push your working-branch to your remote personal github repository by:
 
  git push origin working-branch
 
  E.g.
 
  git push origin bug-99999
 
 
 
If your remote named '''origin''' does not point to your personal github repository
 
but you have another remote which does, then substitute your remote name for '''origin''' in the above command.
 
 
 
If you don't have a remote name that points to your personal github repository,
 
then add a remote name that does, E.g. to add remote named '''mygithub''':
 
   git remote add mygithub ssh://git@github.com/<YOUR-GITHUB-USERNAME>/gnucash
 
then
 
<tt>git push mygithub working-branch</tt>
 
 
 
==== Pull Requests - Create Pull Request ====
 
 
 
* Now log in to your GitHub account, go to your forked gnucash repository, select <tt>working-branch</tt> from the branch pick list, and click ''pull request''. It's above the "last commit" line on the right in the directory view.
 
* In the resulting form, give your pull request a title and describe its motivation. If it's associated with a bug, use the bug number and title for your title and paste the bug URL into the description. Note that GitHub descriptions use Markdown and that there's a preview tab to help you make sure that everything looks the way you want it.
 
 
* Click the ''Send Pull Request'' button to the right of the description block.
 
* Click the ''Send Pull Request'' button to the right of the description block.
 
* If a developer requires changes to your pull request, amend your commits as necessary and force-push your branch. Don't make any changes to that working branch that aren't associated with the pull request!
 
* If a developer requires changes to your pull request, amend your commits as necessary and force-push your branch. Don't make any changes to that working branch that aren't associated with the pull request!
* Once the pull request has been either merged or rejected, you can delete the branch.
+
* Once the pull request has been either merged or rejected, you can delete the branch:
To delete the local branch:
 
 
   git branch -D working-branch
 
   git branch -D working-branch
  E.g.
+
   git push github :working-branch
   git branch -D bug-99999 # delete local branch bug-99999
+
* If you want to continue in between with something else create another branch.
To delete the working branch from your personal remote github repository:
 
  git push <remote-name> :working-branch # note space before :working-branch
 
  E.g.
 
  git push origin :bug-99999
 
  
 
== Committers ==
 
== Committers ==
Line 399: Line 264:
  
 
Sometimes, e.g. after a new release, the first merge in gnucash-docs will result in an conflict about the version number:
 
Sometimes, e.g. after a new release, the first merge in gnucash-docs will result in an conflict about the version number:
<tt>git status
+
<pre>git status
 
# On branch master
 
# On branch master
 
# You have unmerged paths.
 
# You have unmerged paths.
Line 411: Line 276:
 
#
 
#
 
#      both modified:      configure.ac
 
#      both modified:      configure.ac
:</tt>
+
:</pre>
  
 
configure.ac will now contain a section
 
configure.ac will now contain a section
  
<tt><<<<<<< HEAD
+
<pre><<<<<<< HEAD
 
AC_INIT(gnucash-docs, 2.6.99)
 
AC_INIT(gnucash-docs, 2.6.99)
 
=======
 
=======
 
AC_INIT(gnucash-docs, 2.6.4)
 
AC_INIT(gnucash-docs, 2.6.4)
>>>>>>> maint</tt>
+
>>>>>>> maint</pre>
  
 
Just remove the markers and the wrong section with your preferred editor.
 
Just remove the markers and the wrong section with your preferred editor.
  
 
Don't forget to run <tt>git commit -a</tt> to tell git, you are ready!
 
Don't forget to run <tt>git commit -a</tt> to tell git, you are ready!
 +
;Note: Do not confuse -a = --all with --amend!
  
 
=== Link Bugzilla Entries ===
 
=== Link Bugzilla Entries ===
[FIXME:] While this worked with SVN/trac it seems not to work with github.
 
  
 
Often commits are related to [[Bugzilla]] entries. In this case the commit message should contain  
 
Often commits are related to [[Bugzilla]] entries. In this case the commit message should contain  
* '''<tt>Bug #</tt>''<bug number>''<tt>:</tt>''<bug title>''''' or
+
* '''<tt>Bug </tt>''<bug number>''<tt>:</tt>''<bug title>''''' or
* '''<tt>Bug #</tt>''<bug number>''<tt> - </tt>''<bug title>'''''.
+
* '''<tt>Bug </tt>''<bug number>''<tt> - </tt>''<bug title>'''''.
  
 
You can specify it as the first line if the commit fully fixes the related bugzilla issue, or mention it in the body of the commit message otherwise.
 
You can specify it as the first line if the commit fully fixes the related bugzilla issue, or mention it in the body of the commit message otherwise.
 +
 +
Adding these references will make it easier for committers to use the ''git bz'' command while manipulating the commits.
  
 
=== Patches and Pull Requests ===
 
=== Patches and Pull Requests ===
Line 471: Line 338:
 
With rare exceptions we don't want to clutter the master repository with feature branches, so how can two developers collaborate on one?
 
With rare exceptions we don't want to clutter the master repository with feature branches, so how can two developers collaborate on one?
 
There are several ways to go about it: You can pass patches between you over email, chat, or carrier pigeon; Git is designed to handle that easily (except for carrier pigeon transport, as that requires retyping the patch, which is a pain [[http://en.wikipedia.org/wiki/B._F._Skinner#Pigeon-guided_missile Really?]]). You can arrange for all of your repositories to be available on the net, and <tt>git pull</tt> amongst yourselves. Or you can use one of the public repositories like Github or Gitorious to manage your changes.
 
There are several ways to go about it: You can pass patches between you over email, chat, or carrier pigeon; Git is designed to handle that easily (except for carrier pigeon transport, as that requires retyping the patch, which is a pain [[http://en.wikipedia.org/wiki/B._F._Skinner#Pigeon-guided_missile Really?]]). You can arrange for all of your repositories to be available on the net, and <tt>git pull</tt> amongst yourselves. Or you can use one of the public repositories like Github or Gitorious to manage your changes.
 +
 +
= Accessing GnuCash BugZilla from Git =
 +
 +
There is a plugin, called git-bz, written for Git that allows it to talk to BugZilla and do things with bugs like attach patches, add comments, mark as fixed, etc.&ndash;all from the command line. See the [[git-bz]] page for details.
 +
 +
= Htdocs Conversion Notice =
 +
For some time now the gnucash-htdocs repository has been used to store both the website and a compiled version of our documentation in html, pdf, ebup and mobi formats. The problem with this was that the ''compiled documentation'' is pretty large. The repository was finally over 800Mb in size and increasing with each release. That meant that over time a simple clone of the repository would cost increasingly more bandwidth, diskspace and users time.
 +
 +
People that wish to work on the website don't need this compiled documentation so the large download was an unnecessary burden. We have decided to fix this by splitting off the compiled documentation into a separate repository, which is only relevant for a release manager. After the split, the gnucash-htdocs repository has been regenerated without the docs history.
 +
 +
== Update your clones and forks ==
 +
If you have your own clone of the gnucash-htdocs git repository you will have to reclone the new repository if you want to enjoy the smaller footprint. If you have local changes you'll want to preserve them. So instead of deleting the directory rename it. For the examples we'll call it <tt>gnucash-htdocs-old</tt>, and we'll clone into <tt>gnucash-htdocs-new</tt>. That's just to make sure we don't forget which is which. After the import process is complete, you can remove <tt>gnucash-htdocs-old</tt> and rename <tt>gnucash-htdocs-new</tt>.
 +
 +
You've been assiduous about always using <tt>git pull --rebase</tt>, right? No? You've got changes mixed into <tt>master</tt>? No matter. <tt>rebase</tt> to the rescue: (I'm using <tt>master</tt> as an example here, but it could be any tracking branch.)
 +
  cd gnucash-htdocs-old
 +
  git pull --rebase
 +
  git branch -m master foo #This is your new feature branch. You can call it anything you like
 +
  git branch -t master origin/master
 +
  git rebase master foo
 +
There. Now all of your changes are in a nice feature branch. You might have to reconcile some conflicts, but better sooner than later, eh? If you already have feature branches -- we'll use <tt>foo</tt> for our example -- just make sure that it's up to date with its tracking branch:
 +
  git checkout master
 +
  git pull --rebase
 +
  git rebase master foo
 +
 +
Now you're ready to export your changes. Do this one feature branch at the time. Create a set of patches for your feature branch:
 +
  cd ../gnucash-htdocs-old
 +
  git checkout foo
 +
  git format-patch --stdout master > ../foo.mbox
 +
 +
And import your branch foo into the new repo:
 +
  cd ../gnucash-htdocs-new
 +
  git checkout master
 +
  git checkout -b foo
 +
  git am ../foo.mbox
 +
 +
That's it. Repeat for each feature branch and tracking branch. When you're done and really, really sure that everything is properly set up,
 +
you can delete <tt>gnucash-htdocs-old</tt> and any <tt>foo.mbox you created</tt>.
 +
 +
'''Note:''' When you run <tt>git checkout master</tt> in <tt>gnucash-htdocs-new</tt>, git ''should'' respond with
 +
  Checking out files: 100% (1247/1247), done.
 +
  Branch master set up to track remote branch master from origin.
 +
  Switched to a new branch 'master'
 +
''If it doesn't'', then it may have gotten confused. If
 +
  git log --oneline -n 10
 +
doesn't produce the expected results,
 +
  git branch -D master
 +
  git branch -t master origin/master
 +
To get the proper master branch.
 +
 +
;Github Forks: If you have made a Github fork you will need to make sure that your local repo is current and then delete the fork and re-fork the regenerated repository, then proceed according to the instructions above, finally pushing any new branches back to your Github fork.
 +
 +
= Related Topics =
 +
 +
* [https://help.github.com/ GitHub Help] in particular [https://help.github.com/articles/fork-a-repo/ fork-a-repo].
 +
* [[Git Migration]] tracked the required changes to our infrastructure and support code before we were able to switch to a pure git based workflow.
 +
* [[Git vs Svn]] has some background on conceptual differences between svn and git. This may help people with a strong svn background to make the switch to git.
 +
* Purely for historical interest: GnuCash has been maintaining its source code in a hybrid svn-git system for a while. It has now moved on to a pure git environment. We had some documentation for this hybrid setup as well. The current page's history will reveal how a user had to configure her local setup, [[Git_Svn_Mirror]] explains what was needed on the server side.
 +
* [[Git For Newbies]] has basic suggested work flow for modifying GnuCash and more details about what each git command does for those new to git.
 +
* [[Documentation_Update_Instructions]] focuses specifically on documentation updates.

Revision as of 20:36, 20 May 2017

What is Git?

Git is a distributed version control system (VCS) originally developed by Linus Torvalds for managing Linux source code without requiring a central server. It is also the primary VCS used by the Gnome and Free Desktop projects. You can get the latest version for your system and read a rich variety of online documentation at Git's Home. In particular, Pro Git by Scott Chacon is available in several languages for free online reading at Git Book, where you can also download the English version as a PDF, ebook, or mobi.

If you know nothing about version control, that doesn't matter. Just read Getting Started - About Version Control. There in the left column you can select your language.

Another good place to start is Good Resources for Learning Git and GitHub - not only if you want to use GitHub for #Pull Requests.

git help

will give you a list of usual commands and

git help <command>

will show you the manual page of that command.

There are several GUIs available for git, e.g.:

  • git gui
  • gitk (shows the history)
  • SourceTree for Windows or Mac

and most IDEs have plugins for it.

What has that to do with Gnucash?

We are using Git to manage our code and documentation sources.

Our public repositories are mirrored on Github: for code, documentation and for the website. These are updated from the primary repository by commit hooks, so barring technical problems changes appear in these repositories within a few seconds of being committed to the primary.

code.gnucash.org is the server that hosts the canonical git repository, wiki, Mailing Lists, automated win32 builds, and the nightly builds of the documentation and API docs (via Doxygen) for both branches.

Using the Github Repository

Non-Committers

If you are new to using git, you may find it useful to read Git For Newbies for more information about specific git commands and how they are used in the process of modifying GnuCash.

Set-Up

Just clone the repository as usual:

 git clone https://github.com/Gnucash/gnucash.git
other URLs
https://github.com/Gnucash/gnucash-docs (documentation)
https://github.com/Gnucash/gnucash-htdocs (website)
See https://github.com/Gnucash for further repos e.g. with OS/distro specific build scripts.

Branches

There are 2 important branches in most of our repositories:

master
is the default branch in git. New features and their documentation should be based on this branch.
maint
Bugfixes, translations, improvements of the documentation should usually be applied on this branch.

In your local working dir you should checkout one of them, e.g.:

git checkout master

When you have patches in master, use

 git format-patch origin/master..master

(or git diff) in the root directory of your local repository to prepare them; then add the patchfile as an attachment to the appropriate bug report.

GitHub

If you have a Github account, you could as well

  1. use Github's fork feature to set up a clone on GitHub. And then
  2. clone from that repository instead (note that this is your personal read-write enabled clone):
    git clone git@github.com:<YOUR-GITHUB-USERNAME>/gnucash.git
    Note that this clone command takes the URL in a different format.
  3. With this form you will be able to push your local changes to your GitHub account as usual:
    git push origin master
Depending on your access rights you might continue with ... #Pull Requests #Committers

Patches

If you're going to be submitting patches:

  • Create a branch to work in:
    • Bug fixes should branch off of maint unless the bug applies only to the unstable version.
    • New features must branch off of master.

The following example is for a new feature; substitute maint for master if you're doing a bug-fix.

  • Use a particular working branch for only one bug or feature. This will make it much easier to make changes and generate new patches should that prove necessary.
 git checkout master
 git branch working-branch
  • Rebase your working branch onto the target branch often so that you stay in sync:
 git rebase master working-branch
  • Open a bug in Bugzilla to attach your patch to if one doesn't already exist.
  • Write good commit messages in which the bug number and summary are the first line. Skip one line, then describe the patch. For example:
 [Bug 673193] - Possible Register migration to TreeView
 
 Update the old register rewrite branch to work with the currently-released Gtk2.
  • Use git rebase -i as necessary to make a clean series of patches for complex changes.
  • Be sure to do a fresh rebase from the target branch and a make check to ensure that everything works
  • Use git format-patch to create the actual patches from your commits:
 git rebase master working-branch
 git format-patch master
  • Attach the resulting patch(es) to the bug report.
  • If a committer asks you to make changes, revise your original commit and make a new patch. Don't submit a patch to be applied on top of an old one. git-rebase -i can be very helpful if you have a series of patches.

Pull Requests

If you prefer, you can use a GitHub Pull Request instead of attaching a patch to a bug.

  • Fork the Gnucash/gnucash or Gnucash/gnucash-docs repo on GitHub. You'll need to create a GitHub account if you haven't got one already and set it up for ssh access. In the example below, we'll assume a GitHub userid of "Me". Substitute your real id.
  • Add that branch as a remote in your local repository and push your working branch to it:
 git remote add github ssh://git@github.com/Me/gnucash
 git branch -u github working-branch
  • Perhaps an easier approach is to replace the push url:
 git remote set-url --push origin git@github.com/Me/gnucash
 git branch working-branch
  • apply your ammendments and
 git push
  • Now log in to your GitHub account, go to your forked gnucash repository, select working-branch from the pick list, and click pull request. It's above the "last commit" line on the right in the directory view.
  • In the resulting form, give your pull request a title and describe its motivation. If it's associated with a bug, use the bug number and title for your title and paste the bug URL into the description. Note that GitHub descriptions use Markdown and that there's a preview tab to help you make sure that everything looks the way you want it.
  • Click the Send Pull Request button to the right of the description block.
  • If a developer requires changes to your pull request, amend your commits as necessary and force-push your branch. Don't make any changes to that working branch that aren't associated with the pull request!
  • Once the pull request has been either merged or rejected, you can delete the branch:
 git branch -D working-branch
 git push github :working-branch
  • If you want to continue in between with something else create another branch.

Committers

Since 2014-02 all GnuCash repositories are pure git repositories:

  • gnucash
  • gnucash-on-windows: windows installer and build script moved here from gnucash/packaging
  • gnucash-docs
  • gnucash-htdocs (see #Conversion Notice)

Write Access

FAQ: Is it possible to get write access?

A: In principle yes, but we are quite conservative with giving out new SSH write accounts. For occasional changes people are encouraged to submit patches. We do add people as developers if they stick around, supply lots of patches, become highly involved in the project, hang out on IRC, and generally show some level of clue and prove some level of trust. But in the meantime, patches in Bugzilla and pull requests on github are the suggested route, as has been stated at other places. --Cstim 08:00, 8 January 2006 (EST)

Set up

Note: this set up presumes you already have commit access to the GnuCash repositories on code.gnucash.org. If you don't but believe you should, ask for this on the gnucash-devel mailing list.

Generate your ssh key pair

You'll need to generate a key-pair and provide the public half to the GnuCash repository administrator. To generate a key pair use

 ssh-keygen -t rsa -b 1024 -f gnucash-key

You can use any name you like instead of "gnucash-key".

You will also be prompted for a passphrase, with the option to leave it blank. If you provide a passphrase, you will be prompted to provide it every time you use your key. If you don't, anyone who gains access to your key can connect to whatever servers you protect with it.

Once you have the key configured correctly and have provided it to the GnuCash repository administrator, try

 ssh -i gnucash-key git@code.gnucash.org

You'll get the usual ssh question about the fingerprint for a new host. It should be 20:23:3d:df:f3:13:34:c1:32:ca:11:77:24:21:98:01. If it is, answer "yes" to add it to your known hosts file. If you get a message followed by a list of repositories, your setup is correct and you can proceed.

Next, you'll want to to configure your local ssh client to always provide this key when connecting to code.gnucash.org. In addition, ssh should always connect as user 'git'.

On linux, you can set this up by adding the following lines in your ssh config file (~/.ssh/config):

Host code.gnucash.org
IdentityFile ~/.ssh/gnucash-key
User git
(Continue with #Clone the Repositories)
Key generation under Windows
With MSYS

To set up ssh with the MSYS client, proceed exactly as above.

With Putty for TortoiseGit

For [TortoiseGit], you'll also need PuttyGen and Putty from [PuTTY]. Setting up Pageant to work with TortoiseGit is a bit involved, so we'll go through it step-by-step:

1. Use PuttyGen to convert your private key into Putty format. Launch puttygen, click the "load" button and select your private key file, then click the "save private key" button to save it in putty format.

2. Set up a Putty profile: Start Putty.

  • Set the Host URL to code.gnucash.org, port 22 on the Session page
  • Open Connection:SSH:Auth and at the bottom of the panel, for "Private key file for authentication" browse for the converted keyfile you made in the previous step.
  • Open Connection:Data and enter 'git' in the "Autologin username" text entry.
  • Return to the Session panel, enter a name (if you use code.gnucash.org configuring TortoiseGit will be less confusing) in the text entry named "Saved Sessions" and click the "save" button.
  • Click "open". If everything is done correctly, a command window will open and you'll see that message about terminal sessions not being allowed. If you are instead prompted for a password, you have messed up the username or key somehow and will need to contact the server admin to get your IP address unblocked.
(Continue with #TortoiseGit on Windows)

Clone the Repositories

Now clone the Github repository the same way as #Non-Committers. Since changes should not be pushed to the github repository, a good way to make sure that this doesn't happen by mistake is to use the same read-only URI given above for non-committers. Alternatively, fork the Gnucash repository to your Github account and clone that (use the read-write URI in that case).

Next add the repository on code.gnucash.org as a second remote, for example as 'upstream'.

 git remote add upstream git@code.gnucash.org:gnucash

Perhaps a better approach is to replace the push url:

git remote set-url --push origin git@code.gnucash.org:gnucash 

That avoids confusion where to push and where to fetch.

That's it.

(Continue with #Committing)
TortoiseGit on Windows
  • Right-click a folder in Windows™ Explorer and select TortoiseGit:Settings. At the bottom of the Network panel of the resulting dialog box, click the "Browse" button for SSH Client and navigate to C:\Program Files\TortoiseGit\bin\TortoisePlink.exe, click "open" in the file chooser, the "OK" to dismiss the Settings box.
  • Right-click on a folder into which you want to check out (or already have checked out) Gnucash. If it's a fresh checkout, select TortoiseGit Checkout; otherwise select TortoiseGit:Relocate. Enter the URL as ssh://the-putty-session-name/gnucash. (Remember earlier where we said it would be less confusing if you use code.gnucash.org for the session name? That's because if you did the URL will be ssh://code.gnucash.org/repo/gnucash.)

You should now be able to commit changes via TortoiseGit.

Committing

Committing is simple:

 git add
 git commit

These two commands are used to record your changes locally.

 git push upstream local-branch:remote-branch

Will push your changes back to the master repository.

Branching and Merging

The "canonical" repositories at code.gnucash.org and their mirror at github.com/Gnucash have 2 active branches:

master is the development branch. All new features should be committed to this branch and this branch only. Unstable releases during the beta period leading up to a new stable release series will be tagged on this branch and the tarballs generated from the tag commits. Bugs reported against an unstable release should be checked to see if they exist on the stable release; if they do they should be reassigned to the stable release and fixed on maint, then merged. N.B.If for some reason a change is committed to master that should have been done in maint, cherry-pick that commit to maint. Merging master->maint would add all of the development changes into maint, which would be bad.

maint is the current stable release branch. All bugs reported on the released version should have the fixes committed to this branch and then merged to master. Stable releases will be tagged on this branch and the tarballs generated from the tag commits.

There are also archival branches, one for each stable release series no longer under development. Note that before 2.6 we used Subversion or CVS for version control and the practices were different, so you'll see different commit patterns when looking at historical branches.

The gnucash repository contains an archive branch which tracks master up to the point that the last subversion feature branch (webkit, if you're curious) was merged, except that new merge commits have been added to link the feature branch merges. It shows the merge points in the right order, but the merge commit dates are all from early 2014. It is of historical interest only.

There are several abandoned feature branches which were never integrated into GnuCash. They are also present for historical interest only.

Bugs and New Features

To repeat the policy in the description of the active branches:

  • Bug fixes should always be rebased onto the maint branch then merged to master unless either they don't affect maint or they are not going to be fixed on maint because the required changes are complex enough that it would risk making maint unstable.
  • New Features are always rebased or merged onto master. New features are not allowed on maint.

When and how to use branches depends on the complexity of the changes:

  • Small changes, which can be completed quickly and in a single commit, do not require a feature branch.
  • Larger changes, which might
    • require more than one commit or
    • take more than a few hours to write and test
should be done on a private branch which is rebased onto the appropriate main branch before pushing the changes to the main repository. This helps keep the main branch's history linear, which in turn makes it easier to read and displays better in a graphical tool.
  • Major changes,
    • which are completed in stages which are made public in parts or
    • which for any reason are best visualized as standing apart from the main branch,
should be merged with --no-ff to prevent them from fast-forwarding the main branch.

Bug Fix Feature Branch Example

 git checkout -b my-bug-fix maint
 # make changes, commit, test, fix, etc.
 git checkout maint
 git pull --rebase
 git rebase maint my-bug-fix
 # make && make check to ensure that you're not pushing a broken build!
 git push upstream maint
 git checkout master
 git pull --rebase
 git merge maint
 # rebuild and make check again
 git push upstream master

Major Feature Branch Example

 git checkout -b my-new-feature master
 # write and test the first phase of your feature, committing often.
 git checkout master
 git pull --rebase
 git merge --no-ff my-new-feature
 # rebuild and make check for safety
 git push upstream master
 git checkout my-new-feature
 # write the next phase and repeat until done.

Caution: When switching the branch you should cleanup your build dir to avoid "strange behavior". At least you should run make distclean before, but better might be

cd <yourbuild dir>
rm  -rf * && ../configure <your params> && make && make check

after switching. In case you are building intree you can run

git clean -fdx -e /.project -e /.cproject -e /.autotools -e /.settings/

instead to remove everything not in the repository with a few exceptions (-e ...). Above exceptions are files, where Eclipse stores its settings.

Resolving Merge Conflicts

Sometimes, e.g. after a new release, the first merge in gnucash-docs will result in an conflict about the version number:

git status
# On branch master
# You have unmerged paths.
#   (fix conflicts and run "git commit")
#
# Changes to be committed:
#
:
# Unmerged paths:
#   (use "git add <file>..." to mark resolution)
#
#       both modified:      configure.ac
:

configure.ac will now contain a section

<<<<<<< HEAD
AC_INIT(gnucash-docs, 2.6.99)
=======
AC_INIT(gnucash-docs, 2.6.4)
>>>>>>> maint

Just remove the markers and the wrong section with your preferred editor.

Don't forget to run git commit -a to tell git, you are ready!

Note
Do not confuse -a = --all with --amend!

Link Bugzilla Entries

Often commits are related to Bugzilla entries. In this case the commit message should contain

  • Bug <bug number>:<bug title> or
  • Bug <bug number> - <bug title>.

You can specify it as the first line if the commit fully fixes the related bugzilla issue, or mention it in the body of the commit message otherwise.

Adding these references will make it easier for committers to use the git bz command while manipulating the commits.

Patches and Pull Requests

A common committer duty is handling patches and pull requests from non-committers. The procedure for both is:

  • Review the code for formatting, style, good coding practice, good commit message, etc. Make comments and get the submitter to make any necessary changes.
  • Download and apply the patch to the appropriate branch. If the change is complex you may want to make a local branch to work in.
  • Build and test. Discuss any problems with the submitter and get the patch in good shape, ready to commit.
  • If the patch is on the maint branch, do a test merge onto master. Resolve any merge issues with the submitter; if necessary, get a "patch to the patch" to resolve the merge conflicts.
  • Once everything is ready, merge your working branch into master or maint:
    • Reset your local maint and/or master branches to remove any test merges.
    • Pull them to get any commits others might have pushed while you're working.
    • Apply the final patches or merge your working branch. When applying take care the patches are committed with the appropriate authorship.
      • If the patches were created with git format-patch and hence applied using git am this should be ok.
      • Also if the patches are in another repository or branch and you use git pull to apply them the author should be ok as well.
      • If the patches came as ordinary diff files to be applied with git apply, you should commit these changes with git commit --author "name <email>" with the proper author name and e-mail filled in.
    • Merge maint into master if required; if there's a "patch to the patch" to handle conflicts between maint and master, use --strategy=theirs to the merge, then apply the repair patch and commit 'amending the merge commit:
 git checkout master
 git merge --strategy=theirs maint
 git apply patch-to-the-patch
 git commit -a --amend
  • Push the results
  • Close the pull request or mark the patches "Committed" in Bugzilla.

Pull Request Notes:

  • When processing a pull request it's safest to download the pull request as a (series of) patch(es). When you pull from the submitter's GitHub repository branch you risk conflicts because it hasn't been rebased to match the current state of the branch you're pulling to, though you can avoid that by making a working branch from the main branch commit that's at the base of the submitter's working branch. There may also be problems if the submitter has made changes to the working branch after making the pull request.
  • Note that code review comments can be made inline from the "Files Changed" tab of the pull request page on GitHub.

Other options exists as well; feel free to edit this wiki page.

Back to Development Process

Collaboration

With rare exceptions we don't want to clutter the master repository with feature branches, so how can two developers collaborate on one? There are several ways to go about it: You can pass patches between you over email, chat, or carrier pigeon; Git is designed to handle that easily (except for carrier pigeon transport, as that requires retyping the patch, which is a pain [Really?]). You can arrange for all of your repositories to be available on the net, and git pull amongst yourselves. Or you can use one of the public repositories like Github or Gitorious to manage your changes.

Accessing GnuCash BugZilla from Git

There is a plugin, called git-bz, written for Git that allows it to talk to BugZilla and do things with bugs like attach patches, add comments, mark as fixed, etc.–all from the command line. See the git-bz page for details.

Htdocs Conversion Notice

For some time now the gnucash-htdocs repository has been used to store both the website and a compiled version of our documentation in html, pdf, ebup and mobi formats. The problem with this was that the compiled documentation is pretty large. The repository was finally over 800Mb in size and increasing with each release. That meant that over time a simple clone of the repository would cost increasingly more bandwidth, diskspace and users time.

People that wish to work on the website don't need this compiled documentation so the large download was an unnecessary burden. We have decided to fix this by splitting off the compiled documentation into a separate repository, which is only relevant for a release manager. After the split, the gnucash-htdocs repository has been regenerated without the docs history.

Update your clones and forks

If you have your own clone of the gnucash-htdocs git repository you will have to reclone the new repository if you want to enjoy the smaller footprint. If you have local changes you'll want to preserve them. So instead of deleting the directory rename it. For the examples we'll call it gnucash-htdocs-old, and we'll clone into gnucash-htdocs-new. That's just to make sure we don't forget which is which. After the import process is complete, you can remove gnucash-htdocs-old and rename gnucash-htdocs-new.

You've been assiduous about always using git pull --rebase, right? No? You've got changes mixed into master? No matter. rebase to the rescue: (I'm using master as an example here, but it could be any tracking branch.)

 cd gnucash-htdocs-old
 git pull --rebase
 git branch -m master foo #This is your new feature branch. You can call it anything you like
 git branch -t master origin/master
 git rebase master foo

There. Now all of your changes are in a nice feature branch. You might have to reconcile some conflicts, but better sooner than later, eh? If you already have feature branches -- we'll use foo for our example -- just make sure that it's up to date with its tracking branch:

 git checkout master
 git pull --rebase
 git rebase master foo

Now you're ready to export your changes. Do this one feature branch at the time. Create a set of patches for your feature branch:

 cd ../gnucash-htdocs-old
 git checkout foo
 git format-patch --stdout master > ../foo.mbox

And import your branch foo into the new repo:

 cd ../gnucash-htdocs-new
 git checkout master
 git checkout -b foo
 git am ../foo.mbox

That's it. Repeat for each feature branch and tracking branch. When you're done and really, really sure that everything is properly set up, you can delete gnucash-htdocs-old and any foo.mbox you created.

Note: When you run git checkout master in gnucash-htdocs-new, git should respond with

 Checking out files: 100% (1247/1247), done.
 Branch master set up to track remote branch master from origin.
 Switched to a new branch 'master'

If it doesn't, then it may have gotten confused. If

 git log --oneline -n 10

doesn't produce the expected results,

 git branch -D master
 git branch -t master origin/master

To get the proper master branch.

Github Forks
If you have made a Github fork you will need to make sure that your local repo is current and then delete the fork and re-fork the regenerated repository, then proceed according to the instructions above, finally pushing any new branches back to your Github fork.

Related Topics

  • GitHub Help in particular fork-a-repo.
  • Git Migration tracked the required changes to our infrastructure and support code before we were able to switch to a pure git based workflow.
  • Git vs Svn has some background on conceptual differences between svn and git. This may help people with a strong svn background to make the switch to git.
  • Purely for historical interest: GnuCash has been maintaining its source code in a hybrid svn-git system for a while. It has now moved on to a pure git environment. We had some documentation for this hybrid setup as well. The current page's history will reveal how a user had to configure her local setup, Git_Svn_Mirror explains what was needed on the server side.
  • Git For Newbies has basic suggested work flow for modifying GnuCash and more details about what each git command does for those new to git.
  • Documentation_Update_Instructions focuses specifically on documentation updates.