v1 -> v2 Script Converter

[andymbody]

I see that this project is being updated several times a week on github, most recent in last 12 hours.

Just fyi... It looks like it will take some time for me to learn the process for submitting changes, etc on Github. So it will be awhile before the changes I have made make it to that site. I started reading about the process, but may need to watch a couple videos to speed up the learning curve.

You mentioned creating a fork. Do the changes made to forks ever make their way back to the main project, or is a fork intended to be a separate project that is disconnected from the original? If they are meant to remain isolated, it seems (to me) counter-productive to the overall goal of multiple contributors working towards improving the original. Or am I misunderstanding something? I just checked and it appears that there are currently more than 30 forks from this project.

I'm sure the answer to this type of question will become more clear as I learn the process further.

[guest3456]

I see that this project is being updated several times a week on github, most recent in last 12 hours.

Just fyi... It looks like it will take some time for me to learn the process for submitting changes, etc on Github. So it will be awhile before the changes I have made make it to that site. I started reading about the process, but may need to watch a couple videos to speed up the learning curve.

You mentioned creating a fork. Do the changes made to forks ever make their way back to the main project, or is a fork intended to be a separate project that is disconnected from the original? If they are meant to remain isolated, it seems (to me) counter-productive to the overall goal of multiple contributors working towards improving the original. Or am I misunderstanding something? I just checked and it appears that there are currently more than 30 forks from this project.

I'm sure the answer to this type of question will become more clear as I learn the process further.

forks are cheap and easy. anyone can create a fork simply as a backup and then the whole repository gets mirrored into their account.

the collaboration process usually looks like this:

1. fork the project into your own account.
2. keep the 'master' branch of your fork clean, so that you can pull in updates from the main repository as they happen
3. branch off your master branch in your fork to make your proposed changes. this keeps your changes isolated into a branch and doesnt mess up your master branch which should always try to mirror the main repo
4. when your feature is ready, create a Pull Request into the main repo, requesting to pull in the changes from your feature branch from your repo
5. maintainers of the main repo will review your changes and merge them in if they are acceptable

[andymbody]

the collaboration process usually looks like this:

Thank you! This birds-eye view is helpful to get my education started. I will look into these details.

[andymbody]

Making progress getting on board with Github... sent a fake/test pull-request. I was not able to delete it, and the tutorials show that this can only be done using the command line interface, which I do not have yet.

I have made a lot of changes/corrections for ConvertFuncs.ahk with more to come. The thing is, some of the changes involve new functions that have been added to support larger changes yet to come, which (IMO) require more than band-aid code. I'm not sure whether these changes will be welcome in the project or not, because some involve a redesign of the current workflow. The main loop works for many things, but restricts other things. I guess I will submit the changes and see whether they are welcome within this project or not.

I will need to go back to the master branch and start again with the changes so that each can be submitted independently (as requested). I'm unsure whether I will need to wait for each pull-request to be approved before submitting another. But some changes build upon each other. Submitting each change as a separate pull-request will be tedious, but I understand the need for this process. I'm still trying to understand branches and wonder if each change requires a new branch or not.

Please let me know whether I will need to wait for approval of one pull-request before submitting another. And any other thoughts you may have.

Thanks!
Andy

[andymbody]

Submitted my first real pull request. It might have affected the Unicode characters by mistake within ConvertFuncs.ahk. Let me know whether I need to fix this. Also the new global variable may need to be added to other .ahk files, like v2converter.ahk.

[guest3456]

Making progress getting on board with Github... sent a fake/test pull-request. I was not able to delete it, and the tutorials show that this can only be done using the command line interface, which I do not have yet.

I have made a lot of changes/corrections for ConvertFuncs.ahk with more to come. The thing is, some of the changes involve new functions that have been added to support larger changes yet to come, which (IMO) require more than band-aid code. I'm not sure whether these changes will be welcome in the project or not, because some involve a redesign of the current workflow. The main loop works for many things, but restricts other things. I guess I will submit the changes and see whether they are welcome within this project or not.

I will need to go back to the master branch and start again with the changes so that each can be submitted independently (as requested). I'm unsure whether I will need to wait for each pull-request to be approved before submitting another. But some changes build upon each other. Submitting each change as a separate pull-request will be tedious, but I understand the need for this process. I'm still trying to understand branches and wonder if each change requires a new branch or not.

Please let me know whether I will need to wait for approval of one pull-request before submitting another. And any other thoughts you may have.

Thanks!
Andy

you do not need to wait for approval of one PR before submitting another. you can submit as many as you want simultaneously. given this, it is imperative to keep each feature in a separate branch, so that each individual PR is clean. if different PRs build on top of each other, you should note that in the PR comments that that specific PR depends upon another.

it is certainly tedious if you've never used git before, to keep your repository clean and remember to branch off for different features, and also to even keep your individual commits small and contained. as you learn more about git from reading and watching videos, you will see many people stress the importance of this. as a beginner to git you will find yourself spending more time editing your code and organizing your repository commit wise and branch wise. as you get more familiar with the process, you will just think differently from the start, and end up writing the initial code in a more compact way, and committing the changes more often and frequently, to preempt all the manual editing later. you can (and should) always edit your history locally before pushing any changes publicly. you can do this with tools like git rebase which is a command line tool allowing you to go back in commit history and revise commits and edit changes and drop changes. branches are cheap and easy to create and delete so you should get familiar with that process as you will be doing that constantly.

right now all of this will seem meaningless but as you get more experienced with collaborative development you will see the benefit. even if you started using git for your own personal project you will see the benefit of having a clean history when you need to go back and see how/why you made a change and/or why something might have broken. learning git is an investment but very worthwhile for any serious developer. you can browse the commit history of our project to see how each commit is usually a single defined change, with associated test files updated. or if its a refactor sometimes the commit is larger but thats not usually recommended. you can browse other proejcts to see how the commits try to stay small and clean as much as possible. and then PRs are simply a group of small commits (sometimes even just one commit) that create a logical new feature of bug fix etc

[andymbody]

Thank you very much for taking the time to explain some of this to me. It's very helpful with this new journey. I will get more familiar with this over time, of course, but right now it completely new. I have no other comparable workflows to draw similar knowledge/experience from.

Thank you!