A couple of questions on submitting changes.

[grodrigues]

Ok, I have cloned the SR repo and am ready to start pushing commits. I have two types of questions: (1) general GitHub and push policy questions (2) specific questions on particular bug fixes. This post is about (1) and (2) will be dealt with in a subsequent post.

Sorry if some of these questions are really newbie-ish, but I have only managed a GitHub repo over my sole control, and in that case, edit-commit-push is enough.

So my workflow is the following: every patch is done via WeiDU (instead of say, using NI) on the spl, eff, etc. files themselves to keep a record, in WeiDU code, of the exact changes and make it easy to change, reverse etc. The patched spells are then copied into an external folder, reviewed in NI to check everything is fine, and then copied into my local branch. Since I do not wish to delve into SR code, this leads to the first question:

(1) Should I patch the spl (eff, etc.) files from a working installation or from the mod folder (e.g. from my local branch)? If the first option, can I go with my present install: SR on top of a medium stack of mods -- in the middle of setting up a full install -- with biffing on the end or should I trim the install to say, ToBEx, bg2fixpack and SR? If the second option, is not there a risk that any subsequent patching done by SR destroys my fixes?

(2) What is the exact policy to submit changes? How do you guys do it? Create a new local branch for each batch of changes, make the changes to the branch, push the branch (after rebasing master into local branch), and when changes are accepted delete the local branch?

Thanks in advance for any help.

[Mike1072]

1. You should definitely apply your changes to the resource files inside the mod folder instead of the ones installed in the game.  There is little chance that SR patches will override what you do, because SR doesn't really use patches that way.  The patches that exist in SR mostly do things that can only be done at install-time.  
2. If you're comfortable creating separate branches for each feature as you suggest, that's absolutely the best way, because it lets us add further commits on that branch if necessary and then squash when merging.  Many modders are newcomers to git, so this is not a requirement.

[grodrigues]

Ok. Will go the branch way; not too savvy with git but I *think* I can handle it.

[grodrigues]

Sorry to bother, but I am stumped. No matter, what I try (pushing via https over the command line, using GitHub addon on vscode, using ssh with gitkraken) I cannot push my local branch, I am always denied access. My understanding was that the G3 repo's are public. Is some kind of permission needed? If not, there is something messed up with my git setup, or my credentials that I have to sort through.

[lynx]

You can't push to the G3 repos, since you don't have that sort of access. But you can push to your own forks of them. So do that first — there's a fork button on every repo page. You'll have to change what your "origin" origin points to afterwards (edit .git/config or find some command to do it), so you tell git you're working on your own repo/fork. Once you push, the web interface will automatically suggest you create a pull request and make it trivial.

[Mike1072]

Yes, you won't be able to push directly to a G3 repo unless you are the maintainer of the mod.  Our standard practice is for contributors to create a fork of the G3 repo, push their changes to the fork, then submit them to the G3 repo via pull request.

After you create your fork, you can adjust the remotes in your local repo with these commands (using the appropriate URL for your fork in the second).

git remote rename origin upstream
git remote add origin https://github.com/yourusername/SpellRevisions.git

With these remotes, you'll be able to push to origin (your fork) and pull from upstream (the G3 repo).

[grodrigues]

Duh, now I feel stupid. Just a couple of days ago was reading about the fork and pull workflow here and then forgot all about it. Anyway, thanks for everything. PR is in.

By the way, on GitHub I use the nick lambda-dom. Why I chose a nick instead of going by my name (or more correctly, a contraction of my name, G. Rodrigues) I no longer remember. It was probably a very stupid reason.

Edited January 8, 2020 by grodrigues
nick

[grodrigues]

50 minutes ago, Arthas said:

Are you working on the official version, or are you planning to release an alternative third version? (in addition to the official one and Bartimaeus one)?

On the two fronts: pushing fixes to SR and concocting a version of SRR plus some changes of my own devising -- but on the grand scheme of things it will be mostly SRR. But the two are completely separate.No ETA on this though, I have barely begun to scratch the surface. Also, and just in case you are wondering, no use asking for options for this or that, at least not now. And even if I do release a public version (after asking permissions) I tend to be a dictator, and not quite a benevolent one.

[grodrigues]

Made some mistakes with git, but they are solved now. Second PR in.