[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=34&rev2=35

  
  {{{
  $ ls                                 
- api                     checkin_notes_samples  db           
+ api                     checkin_notes_samples  db  
- apps                    client                 debian     
+ apps                    client                 debian
- _autosetup              clientctrl             depcomp    
+ _autosetup              clientctrl             depcomp
  bolt_checkin_notes.txt  clientgui              doc
  [...]
  }}}
@@ -168, +168 @@

  git buildpackage -rfakeroot
  }}}. One could improve that just a bit by not requesting signatures {{{
  git buildpackage -rfakeroot -uc -us
+ }}}. And if you are still evaluating bits here or there without having them checked in or the source tree was not properly cleaned from side-effects of the build, then run {{{
- }}}. And if you are still evaluating bits
- here or there without having them checked in or
- the source tree was not properly cleaned from
- side-effects of the build, then run {{{
  git buildpackage -rfakeroot -uc -us --git-ignore-new
  }}}.
  
@@ -191, +188 @@

  }}}
  <<Anchor(TrackingUpstream)>>
  
- == Uploading local changes to the servers ==
+ == Typical workflow in git development ==
  
- ''This sections needs to be severely updated since the server-branches are now merged''
+ The ''branch'' is the central theme in git development. They are
+ even created for some very quick local idea, just in case that that development may be in parallel to another idea. In short, a branch is some piece of development that one may accept or reject as a whole. It should be treated a bit like as if those changes done to a branch would be meant to get together as a single patch file.
  
- Every new idea worked at under git is prepared as a separate branch. This may for instance be a bug that is fixed. The branches currently existing on the servers seem sufficient. If you are a not a regular contributor, and even if you are, please consider to discuss the preparation of new branches with Rene and/or possibly Thomas. The idea previously prepared is then merged with the local representation of the server's branches.
+ There are local branches (your ideas) and remote branches (someone else's ideas or collaborative branches like the remote upstream or the remote master branch. 
  
- {{{
+ === Working with local branches ===
+ 
+ Every new idea worked at under git is prepared as a separate branch. This may for instance be a bug that is fixed. When implementing something locally you want to
+  1. create a new branch {{{
+ git branch new_unique_branchname
+ }}}
+  2. check out that branch {{{
+ git checkout new_unique_branchname
+ }}}
+  3. implement your change {{{
+ echo "new stuff" >> "some_file"
+ }}}
+  4. commit change to git {{{
+ git commit "some_file"
+ }}}
+  5. when completed the work or tired of it, check out master branch again {{{
  git checkout master
- # checking out the server's branch. Make sure the names are identical
- git checkout -b debian/topic/boinc-server origin/debian/topic/boinc-server
- # now start following your idea
- git branch myIdeaToTest
- # perform some wild editing
- git add <i>files edited</i>
- git commit -m "some summary"
- # you possibly want to have several rounds of editing/adding/commits
- git checkout debian/topic/boinc-server
- git merge -m "bringing idea to life" myIdeaToTest
- # uploading to upstream branch with the same name as the local one
- git push origin
  }}}
- If you don't need your branch any more then you can delete it with
- 
- {{{
- git branch -D myIdeaToTest
+  6. if you have a new idea, go to 1.
+  7. if you want to continue with your development work, go to 2.
+  8. combine your local development with your local mirror of a collaborative branch {{{
+ git merge new_unique_branchname
  }}}
- This way, the changes are done to the respective branch, not to the master. Changes to the latter would impose their applicability across all possible versions of boinc. If the idea of yours that is represented by the branch would be applicable, then merge it from multiple branches, i.e. from debian/etch and debian/sarge, prior to deleting it.
+  9. (optional) delete that branch you have developed in {{{
+ git branch -d new_unique_branchname
+ }}}
+ 
+ The local master branch is now "ahead of 1 commit" of the origin/master branch, i.e. the branch on the remote server
+ that the master branch was cloned from.
+ 
+ If the idea of yours that is represented by the branch would be generally applicable, then merge it from multiple branches, i.e. from debian/etch and debian/sarge, prior to deleting it.
+ 
+ === Uploading local changes to the servers ===
+ 
+ If one is truly happy about the local master branch, then those local changes should become available to the others: {{{
+ git push
+ }}}
+ . If you do not have upload permissions then you can alternatively say {{{
+ git format-patch
+ }}}
+ to have patch files created with your name as an author. For a more anonymous kind of contribution, just show how your debian folder differs from the version of that branch "master" from the same branch on the server referred to as origin (the alioth git repo), try {{{
+ git diff origin debian
+ }}}
+ and send it to the list. The {{{
+ git diff
+ }}} command without the notion of the origin would ask for changes compared to the last committed version, i.e. the latest version locally known to git, not to the latest version on the server.
+ 
+ === New remote branches ===
+ 
+ The branches currently existing on the servers seem sufficient. If you are a not a regular contributor, and even if you are, please consider to discuss the preparation of new branches with Rene and/or possibly Thomas. The idea previously prepared is then merged with the local representation of the server's branches. To have your branch on the remote site, just be a bit more explicit to ''push'': {{{
+ git push origin new_unique_branchname
+ }}}
+ To remove that remote one, use the following (not truly intuitive) syntax: {{{
+ git push origin :new_unique_branchname
+ git branch -d new_unique_branchname
+ }}}
+ . So, one needs to perform the removal of a remote branch both on the remote and the local site.
  
  === Committed everything changed but there are still changes ===
  
  This is mightily annoying, but the build process at times changes files that are part of the upstream source tree but nonetheless changed by the build process. Those problems are to be helped by improving the source distribution (e.g. by removing the config.* files) but does this all work without version.h being at least existing?
  
- Changes to those collaterally modified files should not be committed. When git does not allow you to do anything (like uploading a new upstream) then consider running "git reset --hard" or (more intuitively) changes those files back via
+ Changes to those collaterally modified files should not be committed. When git does not allow you to do anything (like uploading a new upstream) then consider running "git reset --hard" or (more intuitively) changes those files back via {{{
- {{{
  git diff | patch -p1 -R
  }}}
  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.
@@ -259, +292 @@

  == External References ==
  
   * [[http://www.kernel.org/pub/software/scm/git/docs/user-manual.html|Git User Manual]]
+  * [[http://www.gitready.com/|GitReady]] a community web site