Forum OpenACS Q&A: Re: Autmoated test results (five failures)

Collapse
6: Re: Autmoated test results (five failures) (response to 5)
Posted by Antonio Pisano on 02/26/15 11:23 AM
Dear Jim,

the fact that you're fixing this problems is more than ok, I also agree with you that moving to a modern version control system is inevitable.

This said, I suggest everyone to don't let this little changes here and there go unnoticed. Now it's a unit test, tomorrow, fork is in the air.

As a niche, yet compact community, I think this is something we should not go for, so maybe you, Gustaf and Victor could get in contact and decide for a merging strategy. Maybe this could lead to the long praised migration to git.

This is just my opinion, feel free to express yours.

Antonio

Collapse
7: Re: Autmoated test results (five failures) (response to 6)
Posted by Jim Lynch on 03/04/15 08:03 PM
OK...

Here is my workflow, it should also show how and when I merge.

First, I make a fork on github, of openacs/openacs-core, since right now I'm interested in a clean, no-fail automated test result.

Next, I make a clone of the fork, and that gets me all of the core of openacs and (importantly) a remote called origin, which I can write to. At this point I cannot write to openacs/openacs-core, and this is an important point because it informs my workflow. Since I cannot write, I note the 20-someodd remote tracking branches (including origin/master) that I got with the clone.

Because I cannot write, I will not ever alter the branches that came with the clone, except to update them from an additional remote, which I will call upstream.

This remote, upstream, is what I add to point at openacs/openacs-core, for the purpose of receiving the updates that come from the maintainers who can write. I create this remote on my local working dir, by running: "git remote add upstream https://github.com/openacs/openacs-core.git";.

For example, when I think someone has updated master, I will run "git pull upstream master" to get new changes from their master branch. Usually, the merge implied by git pull will be a simple "branch advance" referred in git parliance as a "fast-forward" merge, because I refrain from committing on existing branches.

After doing that, I then update my fork on github, by running "git push origin master".

Right now, bug fixes are to the branch, oacs-5-8. For each bug, I create my own branch. the last one was called doc-issue. The openacs maintainers do not have a branch called this (I checked), so I'm perfectly safe in making it. Once I had something I thought would fix the bug, I pushed the branch to my fork: "git push origin doc-issue" and then I can file the bug report, and in that report I tell them the website address of my fork, and the name of the branch I pushed, which is where I conducted my work.

As long as I never write/commit to the existing branches that came with my clone of my fork of their project, those branches remain clean and can be updated from upstream and pushed to my fork, and will therefore remain identical to their upstream copy. This means I must wait for changes to come from upstream.

This has been a description of my workflow, and the workflow I would suggest for anyone wanting to work with git who also cannot write openacs/* on github.

I think that without too much problem it could serve as a suggested set of guidelines for those who cannot write to the upstream.

-Jim