Blog about my forks at github for the repositories OpenFOAM and ThirdParty
Tags git, openfoam, static, thirdparty
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:
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:
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.
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:
- 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):- master - dedicated to keeping track of the original repository.
- issue256 - relates to Issue 256@OpenFOAM's_Mantis. More information available here (see the first comment).
- issue211 - relates to Issue 211@OpenFOAM's_Mantis. More information about it here (see the commit message).
- issue231 - relates to Issue 231@OpenFOAM's_Mantis. Three patches are logged in the commits, which were all committed to the bug tracker.
- issue256_testscripts - relates to the build time tests reported on Issue 256.
- 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.
- 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
- 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.
- 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):- master - dedicated to keeping track of the original repository.
- 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!
- 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
- OpenFOAM-2.1.x - Branches (chronological order of start date):
- master - dedicated to keeping track of the original repository.
- I had two branches that were based on code retrieved from a project at SF.net, from these guys: But the other day the Extend project at SF.net got wrongly targeted in a take down notice: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 |- https://twitter.com/swakPyFoam/statu...62095041204226
- https://twitter.com/swakPyFoam/statu...15485217636353
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
Three classes in the lduSolvers-library. Can't remember the exact names but they are not essential (removing them lets the rest compile OK)
- ThirdParty-2.1.x - Haven't done anything yet here...
- 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:
This forced my repository to go back to the common commit and then I could push from the original "master" to my fork.Code:git checkout -b mymaster remotes/mygithub/master gitk #interactively change position of the mymaster HEAD git push mygithub mymaster:refs/heads/master -f
Total Comments 1
Comments
-
Instead of editing the blog post and tampering with the historic dates mechanism, I've decided to write a comment instead, on the status of this line of thinking.
Essentially, I started dealing with so many repositories and trying to help so many people on the forum, that writing on blog format sort-of became obsolete.
Nonetheless, I still do have a blog of sorts and is maintained here: http://wyldckat.github.io - although it currently points to the wiki for the same project, since it's easier for me to edit locally and git commit+push: https://github.com/wyldckat/wyldckat.github.io/wiki
Either way, I haven't been doing as many forks and have been contributing more directly to projects, therefore any breadcrumbs on what I do are mostly kept on their respective bug/issue trackers, repositories and project pages.Posted January 9, 2016 at 10:41 by wyldckat
