Jon's cmake fixes

[rgleason]

add version major.minor.patch.tweak redundant ignore files

[mauroc]

I am sorry @rgleason , I am at a loss understanding this PR. There are commits such as "Merge pull request #5 from leamas/reset35" that I had accepted a while ago. Why is it showing up again? It may be my lack of understanding of git. Perhaps some context on what this is all about would help

[leamas]

I don't think anyone has enough understanding of git to get this history. It would probably be better to start a new branch from current master and cherry-pick the three commits which are supposed to be good:

$ git remote update upstream
$ git checkout -b jon2-fixes upstream/master
$ git cherry-pick  a55bb4d
$ git cherry-pick  f8de02e
$ git-cherry-pick 331084d

And then add submit a new PR based on this somewhat more sane branch (Hey, this is starting to be a git crash-cource...)

[mauroc]

@rgleason please resubmit as per @leamas suggestion above

[rgleason]

Thanks for your patience. I asked about this before, when I sent the compare. If you don't understand it, do I have any chance? ...I think It was simple. Awhile ago I made a PR from your leamas:reset35 to learn more and to rebase od-fixes onto that. This was done onto a separate branch I had checkout from rgleason:master which I called rebase35-rg. -- So I guess this where it came from.

One of these days I'll get the full picture, ...so it is very important to create a history that people understand? I thought it just had to work, but I didn't think those Oct 12, Oct... PR's were very useful anyway.. However the changes being made were consistent with what I intended and they built and deployed!

Thanks for the instructions. It looks like "git cherry pick" is something I really absolutely need to know.

What about this? "This will not fly. There cannot be two conflicting definitions of PLUGIN_VERSION_PATCH in a C header file."

So like Jon, I am not going to do anything at this point.

[rgleason]

BTW, In any case, I need to get my master to be identical to Mauro's, otherwise I will always have to cherry pick.

That is why I asked earlier about fixing my master by from my local master, git pull upstream master --force git push origin master --force

[leamas]

Rename your current branch: git branch -m master master.old. Fetch a new copy: git fetch upstream master:master. Start working on it: git checkout master

[rgleason]

That is also a new way for me.

git branch -m master master.old
git fetch upstream master:master
git checkout master

When I do this, aren't the releases that I did since Opencpn v5.0.0 that also had Jon Gough's OD points, going to disappear?

Note: Mauro was not around and did not merge Jon's PR for awhile, then we just kept going using my repository for releases, now mauroc:master has the deploy repository since he recently updated travis and appveyor.

These are the commits I'd rather not loose. https://github.com/rgleason/squiddio_pi/releases

• squiddio_pi-0.7.5-win32-Ov4.99-with-OD-BETA.exe
• v1.0.5
• v1.0.6
• v1.0.7
• v1.0.8
• v1.0.9

All the more recent ones are from testing with my cloudsmith repository.

[rgleason]

Maybe it is not worth worrying about that history that mauro does not have? What do you think? I wonder if the commit will still be recoverable from within the Release Tab> Release links for the Tag version and commit hash? example https://github.com/rgleason/squiddio_pi/releases/tag/v1.0.9 v1.0.9 478b2e7

[leamas]

A reachable commit is never lost. Basically, this means that as long as there is a tag or branch pointing to a commit it will not go away.

As I understand it, released tarballs won't go away either, but you should talk to someone else on this -- I have just some superficial understadning of Github tabs & releases.

[rgleason]

Thanks. Yes, I understand. I think I will write support at github so that I really know how to handle this properly.