[Debian Wiki] Update of "BOINC/Development/GitUsage" by SteffenMoeller

[Debian Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Debian Wiki" for change notification.

The "BOINC/Development/GitUsage" page has been changed by SteffenMoeller:
http://wiki.debian.org/BOINC/Development/GitUsage?action=diff&rev1=35&rev2=36

  #language en
+ #pragma section-numbers 2
  #pragma keywords pkg-boinc, parallel computing, volunteer computing, distributed computing, Debian, Linux, Ubuntu, package creation, git, git-buildpackage
  #pragma description Preparation of Debian package from pkg-boinc git repository for distributed computing with the Berkeley Open Infrastructure for Network Computing
- 
+ ~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: none-~
+ ----
  = Packaging BOINC with git =
  
  This page is work in progress. Please contact us if you are keen to receive an update. Such external stimuli often help :)
+ <<TableOfContents(3)>>
  
+ <<Anchor(Overview)>>
  == Overview ==
  
  The general workflow for using the repository is to first have all upstream code in the collaboratively maintained remote branch 'upstream'. Several parallel efforts are kept on the server. The one last uploaded is always in the branch 'master'. One checks out the branch one wants to work with for performing the Debian packaging (maybe 'master') and merges all of upstream into it. Git-buildpackage will then perform the building.
@@ -23, +27 @@

   * debian/experimental
   * debian/<codename>
   * debian/backports/<codename>
-  * debian/fb/<feature>
  
  And there is this special branch here
   * pristine-tar
  which is not really required if one is only interested in the very latest source tree (as we are for boinc) but which plays into our hands once we support many different versions. Let's ignore this for now but find the 'pristine-tar' section below at a later time.
  
- After a first checkout of the repository (cloning in git terminology, described below) a list of branches available on the server is made visible with
+ After a first checkout of the repository (cloning in git terminology, described below) a list of branches available on the server is made visible with {{{
- 
- {{{
  git branch -r
+ }}}
+ and they will then appear prefixed with the term 'origin' {{{
+ $ git branch -r
+   origin/HEAD -> origin/master
+   origin/debian/backports/etch
+   origin/debian/backports/hardy
+   origin/debian/backports/jaunty
+   origin/debian/backports/sarge
+   origin/master
+   origin/pristine-tar
+   origin/upstream
  }}}
  
  == Preparation ==
@@ -262, +274 @@

  }}}
  The latter won't work for changed file permissions (hey, who opts at patching patch for that?) but it is not so bad and the rest can be helped by some "git diff | grep ^diff | cut -f3 -d" " | xargs -r chmod " magic.
  
+ == Get updates in ==
+ 
+ For me to understand how git works I keep thinking about it as a collection of patches to some common seed version. That seed can be empty. Every commit of mine produces a new such patch. When another repository wants to profit from my work, then it needs to take my
+ commits/patches and curate those into their latest version. When there is a change required to do so, then this creates another patch on top of the curated-in (aka merged) patches.
+ 
+ So, the inclusion of remotely created work takes two steps / commands:
+  1. ''git fetch'' - get all that you can from some other repository (or the one that was cloned from by default). The fetched patches are then locally available in the branches like 'origin/master' or 'origin/upstream' but not yet seen when checking out the local 'master' or 'upstream' branch. And one cannot change into the 'origin/*' branches directly, or more correctly, you can, but this does not fit here.
+  2. ''git merge origin'' - take all the patches that some branch has but the local branch has not and apply them. The default is to merge from the branch with the same name of that other repository.
+ 
+ The presumably typical learning curve goes like: "git fetch; git merge" is too tedious, I should be using "git pull" instead, which does the same thing but fetches and merges everything with the same name. And then one has somewhen merged bits that one did not intend to merge as of yet and then goes back to "git fetch; git merge" again.
+ 
  == Don't do this but interesting to know ==
  
  This tutorial is still evolving, and I am afraid it stops here for now. The following tidbits stil need to find their place.
@@ -288, +311 @@

  
   * [[Alioth/Git]] - Instructions on "Using Git on Alioth"
   * [[Horde/GitUsage]] - Some very practical instructions to be adapted from Horde
+  * [[DebPkg:boinc]] - Overview on current versions of Debian packages for BOINC in multiple distros
  
  == External References ==