CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums

Blog about my forks at github for the repositories OpenFOAM and ThirdParty

Register Blogs Members List Search Today's Posts Mark Forums Read

Rate this Entry

Blog about my forks at github for the repositories OpenFOAM and ThirdParty

Posted September 17, 2011 at 05:36 by wyldckat
Updated February 2, 2013 at 06:44 by wyldckat

Note: This blog post will be edited whenever more details come to life.

A bit of an introduction:
I started my experience at github by forking the ThirdParty-2.0.x repository back in 12th of August of 2011. The objective was to create a branch named get-em which would possess modifications for a simple package manager for OpenFOAM's ThirdParty folder, to then be posted as a proposition for a feature request at OpenFOAM's bug tracker. This was not requested by any of the OpenFOAM trade mark holders.

More introduction:
A few days later, the news about OpenCFD being acquired by SGI broke out, and certain fateful paragraph on that news page hit a nerve:
Quote:
The company invites every scientist, developer, engineer and student working in the field of CFD to join the OpenFoam community, download the software for a test drive and to make their own contributions.
The last part of this sentence triggered me to post a certain bug report #276. Update: a year and 4 months later, said bug report was deleted a few days after the unsupported community repo was open: http://www.openfoam.org/contrib/unsupported.php
Either way, later on I went ahead to get into the whole Github social coding thingamabob and started branching out previously submitted patches and also working on top of other peoples patches.

My forked repositories:
  1. OpenFOAM-2.0.x - here I keep my modifications that may or may not become propositions to be placed at OpenFOAM's bug tracker.
    Branches (chronological order of start date):
    1. master - dedicated to keeping track of the original repository.
    2. issue256 - relates to Issue 256@OpenFOAM's_Mantis. More information available here (see the first comment).
    3. issue211 - relates to Issue 211@OpenFOAM's_Mantis. More information about it here (see the commit message).
    4. issue231 - relates to Issue 231@OpenFOAM's_Mantis. Three patches are logged in the commits, which were all committed to the bug tracker.
    5. issue256_testscripts - relates to the build time tests reported on Issue 256.
    6. issue236 - relates to Issue 236@OpenFOAM's_Mantis. This was just a crazy hack for outputting an error message prior to a segfault. A much nicer modification was later on made by Mattijs on this commit.
    7. staticBuilding - the idea for automating static builds of OpenFOAM binaries isn't new, but I've been brewing such idea in my own mind and eventually was triggered by this thread: Anyone successful on static executable solver? - For more on this subject, read my posts on that thread
    8. issue293 - relates to Issue 293@OpenFOAM's_Mantis. Proposition for generating a military like Dog tag, in case embedding the version with DEFINEs is out of the question.
  2. ThirdParty-2.0.x - here I keep my modifications that may or may not become propositions to be placed at OpenFOAM's bug tracker.
    Branches (chronological order of start date):
    1. master - dedicated to keeping track of the original repository.
    2. get-em - a branch designed for a proposed simple package manager for OpenFOAM's ThirdParty. This allows the explicit usage of two dedicated git repositories for both OpenFOAM and ThirdParty repositories, instead of having to provide a default tarball for the git version. This later proposed at Issue 278, where you can find additional instructions on how to use it!
    3. binutils - a branch for servicing binutils building scripts to the following blog post: Building OpenFOAM 2.0.1 on old Linux OSes - test case Ubuntu 8.04
  3. OpenFOAM-2.1.x - Branches (chronological order of start date):
    1. master - dedicated to keeping track of the original repository.
    2. I had two branches that were based on code retrieved from a project at SF.net, from these guys:
      Quote:
      | This is another OpenFOAM extend project developed by NUDT Exercise |
      | Group. lduSolvers was transplanted to OpenFOAM-2.1.0. |
      | |
      | Group: NUDT Exercise Group |
      | Institution: School of Computer, NUDT |
      But the other day the Extend project at SF.net got wrongly targeted in a take down notice:A few days later the problem seemed solved and the actual project apparently was the one that this particular NUDT group had at SF.net, namely this one: http://sourceforge.net/projects/exercisegroup/
      I took out those branches, to avoid being targeted as well.
      More days later, my assumption apparently might be wrong, since Extend got hit again, due to some classes that were ANSYS' copyright: https://twitter.com/swakPyFoam/statu...45802523979776
      Oh well...
      Update 2013 Feb 2nd - well this explains everything:
      Quote:
      Originally Posted by gschaider View Post
      Three classes in the lduSolvers-library. Can't remember the exact names but they are not essential (removing them lets the rest compile OK)
  4. ThirdParty-2.1.x - Haven't done anything yet here...
Notes:
  • Do NOT use Github's "Fork Queue" online tool. It's highly annoying, because it doesn't do the merge's properly.
    In other words, since I have the "master" branch working for both the original repository and my own repository, if "Fork Queue" is used, those master repositories no longer will be compatible. In the end, I ended up doing:
    Code:
    git checkout -b mymaster remotes/mygithub/master
    gitk #interactively change position of the mymaster HEAD
    git push mygithub mymaster:refs/heads/master -f
    This forced my repository to go back to the common commit and then I could push from the original "master" to my fork.
« Prev     Main     Next »
Total Comments 0

Comments

 

All times are GMT -4. The time now is 05:10.