Difference between revisions of "Git"

From GnuCash
Jump to: navigation, search
(Newer git commands must be used without hyphen)
(added github clone address)
Line 4: Line 4:
  
 
Note: You should install git >= 1.5.0 because svn handling has improved considerably with these versions. Really. Don't bother with any 1.4 version; it plainly sucks in comparison to the latest versions.
 
Note: You should install git >= 1.5.0 because svn handling has improved considerably with these versions. Really. Don't bother with any 1.4 version; it plainly sucks in comparison to the latest versions.
 +
 +
There is a git clone at http://github.com/timabell/gnucash/ though it is likely to be out of date as github doesn't support tracking remote svn repositories. (cloned 31 jan 2009)
  
 
== Single Branch Setup ==
 
== Single Branch Setup ==

Revision as of 21:41, 31 January 2009

Git is an extremely cool version control system, but a bit geeky to get used to it. For gnucash, it can be used to hold a local copy of the full svn repository, which means extremely fast version browsing. Also, it is possible to prepare your commits in your local repository first, and sending them to the gnucash svn server sometime later in a batch. Also extremely cool.

Webpage: http://git.or.cz

Note: You should install git >= 1.5.0 because svn handling has improved considerably with these versions. Really. Don't bother with any 1.4 version; it plainly sucks in comparison to the latest versions.

There is a git clone at http://github.com/timabell/gnucash/ though it is likely to be out of date as github doesn't support tracking remote svn repositories. (cloned 31 jan 2009)

Single Branch Setup

If you want to checkout only one single branch, here's what you would do:

Here's how you as a developer get your local git repository if you only want trunk (git-1.5.2):

git svn clone -r16500:HEAD svn+ssh://USERNAME@svn.gnucash.org/repo/gnucash/trunk

That's it. The revision subset r16500:HEAD will download approx. 30-40 MB of data. If you download larger revision spans, the download amount might go up into the hundreds of MBs.

Here's how you run the equivalent of "svn update":

git svn rebase

That's it.

Once you committed your changes to your local git repository, here's how you commit the local changes upstream into gnucash's SVN repository:

git svn dcommit

Multi-Branch Setup

If you want to checkout all of the currently active branches and have the ability to merge and cherry-pick back and forth between all branches locally, here's one way that works:

First of all, it is recommended to use multiple git repositories - one for each branch that you want to work with. This is because when changing between the branches, git would change your working directory, hence everything would need to be rebuilt.

(... FIXME: more text later ...)

git svn clone -s -r16500:HEAD svn+ssh://USERNAME@svn.gnucash.org/repo/gnucash all
cd all
git branch --track my-trunk remotes/trunk
git branch --track my-2.2 remotes/2.2
cd ..

This will need git svn --fetch-all rebase so that all SVN branches are updated in parallel.

Creating a working copy for trunk:

cd all
git checkout my-trunk
cd ..
git clone -s all trunk

And another working copy for branches/2.2:

cd all
git checkout my-2.2
cd ..
git clone -s all 2.2

Building one branch:

cd 2.2
./autogen.sh
mkdir build
cd build
../configure --some-options-foo-bar --prefix=/opt/experimental .....

(... FIXME: more text later ...)

Here's how you as a developer get your local git repository if you want trunk and all branches (git-1.5.2), pay attention to the -s switch:

git svn clone -s -r16500:HEAD svn+ssh://USERNAME@svn.gnucash.org/repo/gnucash
git reset --hard remotes/trunk

The latter command is necessary if your local master should represent the trunk of SVN, which is probably what you want. You need reset --hard here instead of rebase because the revision subset r16500:HEAD probably doesn't contain the original branch point between some of the other svn branches and trunk. If the branch point is included in your cloned revision subset, git rebase remotes/trunk would work as well and is safer (i.e. won't throw away any local changes without asking).

Starting at r16500 is a good opportunity because the 2.2 branch is branched at approx. r16560; if you need the gda-dev: that one was created at r15090.