Synching a fork to main

[lscheffler]

disclaimer:
I use the simplified forms like .git folder, master branch and assumptions the like. I know better, but let's keep it short.

@Jimrnelson
As we found in VFPX/GoFish#121 (comment), it is not very simple to merge code to the VFPX projects.

Those are the ways I would try to solve it:

The common way

The primary idea to solve this is branches. One set up a branch here on github and forces everybody to pull request to this branch.

• If the source is a known contributor doing all the little steps, one can merge on github. At least this should work somehow, not really my way, but I guess a google will do.
• Or, or if the contribution is to be checked, or only partial, one would proceed on local comp
  • merge to the extra branch on github.
  • get the remote branch to your comp (either you have set up this branch while creating it or it is not that tricky. Anyway, if there is a need for help, do not hesitate to ask.)
  • test, merge whatever, a workflow could be found with google

It might be possible to force github to auto-create a new branch on pull request each time. Only from my POV github is a numb back-end to have common remote repos, so do not ask me.
It might also be possible that a contributor pushes directly to the main github repo, just not to master branch. I have no idea how to control this on github.

The on-foot way.

Download the files / the repo from the fork to a temp folder, work it into your code using file explorer, copy'n'paste or the like.
Just like what you do if a solution is posted as a snippet or file attached.

The tricky branch / merge

• in your local repo
• coward like me do a CTRL+C / CTRL-V to the whole base directory to create a backup of the whole thing with the .git folder. Simple to restore. :D
• create a new remote. (git remote add .. on bash, however a GUI will work) to the contributors github repo.
• pull the branch from this new remote. The tricky part is, you need to name this branch locally different then master. Ask me if you need to know how one does it on bash, but not before. If you like to do this on some GUI, you are on your own.
• now you have the foreign code on your comp, proceed like on the first part. (test, merge whatever ...)
• If finished, you can delete the remote and the contributors branch.
• cancel the merge on github
• push

The brute force

• clone the contributors repo to your comp
• copy'n'paste to your usual working directory, test, or however
• push your repo
• delete the clone (watch out to not delete your working dir ...)

Conclusio

All of that is not straight forward and needs some setup or learning branches and merge. The first solution is the simplest way, since one have to learn and setup just once, it's just pull - merge (and rework) - push after.

For the stuff I contribute to, I have one local repo, that talks to my private git server (iow local), pulls from VFPX/xyz/master and pushes to myfork_of_xyz/mybranch, and from there I start the pull request. I do a lot of intermediate commits one will not see in that what I finally push, but this is a different story.

Update:
All this is without the havoc of binary sources, what complicate merges like hell or, from my POV, not practicable with git's common tools without recreating the binaries. (but then they are even more bloat.)

[Jimrnelson]

Thanks, very helpful

[lscheffler]

We need to setup a common way we could all work with for ALL VFPX repos. One need to discuss in more detail, only I fear this is the complex for such messages like this.

[Jimrnelson]

Working with ALL VFPX projects is overkill, as so few of them active. Most have been dormant for a long long time.

And I would hope we could find the simplest way possible in attempting to resolve this relatively rare occurrence.

And by simplest, I want to keep in mind those of us who are not as proficient in git as you.

[lscheffler]

@Jimrnelson

• First things first. We need to figure out an algorithm everybody can agree with.
• Then we set this up for a working project
• Then for the other active ones
• Then, if we have it simple enough, for the dormant ones. This is:
  • at least a common .contribution file
  • and the .gitattributes file
  • and whatever we need as a default
  • this we can do with a script
  • possibly lift *.??2 files to latest version
  • most of that is a script we can do over and over

Me, proficient in git? LOL. I guess I just have two benefits: I using git on command line, aka bash, and I'm willing to google it up (for that, the bash not cmd, there is more information on the LINUX side). The rest is the knowledge that one simply can backup a directory with CTRL+C CTRL+V and try it. It's hard to destroy anyway.

I would think one could set up a project (a duplicate of something we use or some text files) and simply try it.

Learning branches and merges is valuable in itself, so I recommend this way.

[Jimrnelson]

First things first. We need to figure out an algorithm everybody can agree with.

I am far from being convinced that there is a need for this and I see absolutely no urgency for it.

For the projects I manage, the only one I can imagine being affected is Thor, and I believe my changes to Contributing.MD are sufficient.

[lscheffler]

@Jimrnelson Possibly a way out of the problem in VFPX/GoFish#121 (comment):

• pull GoFish to get a recent state
• create a branch on 54467d6, ``Merge pull request`
• push the branch to github
• Then checkup https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request to change the base of the pull request
• merge (pull??) the pull request
• pull to local
• include the branch into your local work

Anyway, aside low level download, I see no way around branches.

[lscheffler]

@Jimrnelson If you like, we can try with Thor itself, and my update for the un-packing. You don't need to be afraid to destroy something git side, this is all made to be resistant. The chance to loose something is near 0.

[lscheffler]

@Jimrnelson There is no danger. NO NIL NOTHING. Not more then adding a file or changing code.
And the change is a good real life example. All what it needs is a new branch. If you got an anxiety problem testing this, it's so simple to do it isolated, so it could never push to this repo. The good on git is, as long as you don't push, all is local, and simple to backup, and easy to undo, as long as you commit any change.

Otherwise we need something else to test.
I like to do such stuff as close to real life as possible, people have better focus then. :D

[Jimrnelson]

@lscheffler

To be clear:

• I do not see any need for this now. It provides for an event that may never recur. Even if it should recur (for Thor), I think the directions in CONTRIBUTING.md are sufficient.
• I do not have any time or interest in working on this.
• Should the time come where I have need for working on branching in git, a time of my choosing, it definitely will not be by working with Thor.

[lscheffler]

But it is understood that a pull request to main, resulting in a merge on github, pulled to your computer while you worked on keeps you in a merge that is much more ugly to solve then a branch? If I had anxiety about branches, I would stuck in pure panic on that.
The problem to solve is the finally the same, only the one is like a stroll on a sunny afternoon. (Just the pro tip: to fix it, one creates an on-the-fly branch)

I do not have any time or interest in working on this.

Then you should not work with git aside numb adding and commit. From my POV, do never issue a merge. Or you must work git like VSS. But then better use VSS, it does the file locking by itself, and not synthetic as you must work git.
Sorry, but you bought a plane, and now you are only able to open the hangar door.

I'm pissed that you force me to work your crap only because you are unwilling to RTFM. Or how do you think I can make my changes so that you with your very limited skills are able to merge something I pull requested before you finally pushed? Thank you for nothing.

---

@Jimrnelson, @DougHennig I'm unable to test changes to my Thor projects, since the unzipping does not work, Jim does not provide a fix nor a trustable way to publish the changes from my fork to Thor. I sit on a heap of fixes, some critical to FoxBin2Prg and there is nothing then whining unwillingness to learn. I offered a learning session before and was rejected, and there is no progress. This is a simple tool, the stuf to learn is, compared to VFP, DBX command and not SQL. (－‸ლ)

That means the repos under my control

• GoFish
• FoxBin2Prg
• Bin2Text
• SF_RegExp

will only receive fixes to the code, no update to there Thor part. I will start today to roll this out.

I can no longer participate on

• Thor
• VFPXDeployment

, aside I push my changes to my fork, and somebody gathers them from there.

[Jimrnelson]

@lscheffler

I have provided you with two distinct steps you can take here:

[1] You can submit your two changed PRGs in a pull request for evaluation whether they will be implemented in Thor.

[2] In the meantime, you can save those two files in your "My Tools" folder so that they will work in your local Thor and no longer impede any of your other VFPX work.

[DougHennig]

@lscheffler We all get frustrated at times, but personal attacks like these comments are completely uncalled for. I suggest you apologize to @Jimrnelson.

[lscheffler]

Additional stuff for setting up github

Make sure the master branch is protected. Do this for all repos, do not argue about this. As long as the repo is not protected, everybody with a very little knowledge of git can remove all data or plant something. This is basic.
If you open a repo and it looks like this

Press the button marked and set like this

---

If we go for the The common way and a branch for merging is created, go to the repositories Settings, General page. There is a Default branch item, set the branch to merge to the new merge-to-branch.

---

I do not know or understand how to set default branch protected for new projects, but then this is only github. ¯\_(ツ)_/¯

[Jimrnelson]

@DougHennig

I am not seeing anything like this when I look at https://github.com/VFPX/Thor, so I am not sure what I'm missing.

In any case, I believe that this would be yours to handle, if you so determine.

[DougHennig]

@Jimrnelson I see this in Settings:

Yes, this is something I would handle. I need to research the implications first.

[Jimrnelson]

Ah, got it. Apparently, since it's not my repo, I don't even see the button for Settings.

[lscheffler]

@Jimrnelson Only the owner can alter such settings.

Update: Try one of your forks.

[lscheffler]

There is nothing more to say or to learn here. I do not see why a question like VFPX/GoFish#121 (comment) is posted the first hand, when all response to the answer is that somebody is unwilling to learn. This time was wasted.