AMB_25-10-14_Multiple_Fixes

[andymbody]

Corrections/Fixes for - not separated
Issue #118 (1)
Issue #202
Issue #328
Issue #358
Issue #384 (2)
Also some refactoring of code and vars

Trying to figure out a branch strategy that prevents duplicate code submission while waiting for (my) previous PR's to merge. (If it is even possible). This is my last submission until I figure it out.

[mmikeww]

of course it is possible. and yes its worthwhile for you to devote the time and mental energy to figure this out. it will take time, and as i wrote before, you will feel like its tedious and a waste of time, but i implore you to push through it and actually learn git properly. there is a reason why its so widespread and prevalent

look at this PR. you have fixed 4 issues in a single commit. then added a few more commits on top. thats is not how it should be done

usually how i do it, is i branch off from master and create new branches for each individual issue or bug fix. the only time i'd combine them is if all of the fixes end up being related and RELY on the same code. otherwise, you should be making each change separate, and then you can PR separately, and code can be merged separately

to visualize, lets say i wanted to start work on a new fix for problem#1, i would do something like:

git checkout master        # make sure i start on master branch
git pull                   # make sure i'm up to date with the web repo
git checkout -b fix1       # start a new branch named "fix1" to do my work
# do work
git add                    # add the files to the staging area
git commit                 # commit the staged files to the new fix1 branch

and the branches now look like this:

fix1                    --O3
                       /
master          O1---O2

suppose i'm tired of working on fix1. or i'm stuck. or i'm finished. and then i decide i want to work on fix2. now, as long as fix2 doesn't require me to use the new code i just did in fix1, i should go backwards and branch back off of master, and NOT build on top of my existing work that i did in commit O3

wrong:

fix1                    --O3---O4
                       /
master          O1---O2

right:

fix1                    --O3
                       /
master          O1---O2
                       \
fix2                    --O4

to accomplish that:

git status                     # currently on fix1 branch, just finished committing O3
git checkout master            # switch back to master branch
git checkout -b fix2           # start a new branch off of master
git add
git commit                     # commit O4

what this means is, all my work on the fix2 branch, will never see the code in fix1. that code will not exist, you will not see it in your working files. same when you're working on the master branch. and then only when you use git and switch to that branch, will you then see that code. and then you will not see any code in master or fix2 that has been added on top of those branches since the branch point

i really encourage you to take the time to experiment. i make liberal use of git checkout branch and gitk to bring up a gui to see what commits have been added to a branch and then switch back and forth

if your code DEPENDS on existing bug fix code, you should STILL create new branches. suppose fix2 depends on the code in fix1. then you should do this:

git status                     # currently on master branch
git checkout fix1              # switch to fix1 branch
gitk                           # last commit was O3
git checkout -b fix2           # start a new branch off of fix1
git add
git commit                     # commit O4

which would look like this:

fix2                         --O4
                            /
fix1                    --O3
                       /
master          O1---O2

you will get annoyed, you will forget, your code will overlap and be in wrong branches, but thats simply part of the learning process. it will take time and you will be frustrated. but after a year or so your code quality will improve because your mind will start thinking differently when you approach how you want to fix your code

[mmikeww]

branches are so powerful because they are disposable. in fact when you are doing your testing you should create a new branch and screw around and branch off and you can completely trash your git history, and it wont matter because at any point you can simply checkout back to master branch and everything is safe. or you could experiment in an entirely new project

lets go back to the preferred method

fix1                    --O3
                       /
master          O1---O2
                       \
fix2                    --O4

this is preferred even if some of the code overlaps. what will happen then, is suppose fix2 gets merged into master first, and then fix1 is attempting to merge back into master. if there is code that overlaps, you will end up with what is called a "merge conflict". you can google and find tons of examples. then it will be up to the person merging to resolve. if you are merging locally on your machine, that will be you. if we are doing a pull request on github to merge changes, then up to the person doing the PR merge

in the last post i was only talking about local development on your local machine, and managing your personal git repo on your machine. which is the first step you need to learn. even if you never use github and do public contributions, you should be doing all personal development with git just the same. its that much worth it

git also allows remote repositories for collaborative development. github and gitlab are the two biggest platforms, but i think you could even just use random IPs if you wanted. when you are interacting with remote repos, the terms are different but the functionatlity is similar. instead of branch we call it fork, instead of merge we call it push or pull

so mmikeww/AHK-v2-script-converter exists, and you decide to create a fork. thats your own personal duplicate. just like when you create a new branch locally. you fork it on github, and then you have your duplicate at andy/AHK-v2-script-converter where you can do your work and experiment without messing with the mmikeww fork

for most collaborations, you should aim to keep your fork in line with the main project. i believe github has a button for that. otherwise you could create a Pull Request on the andy repo, to pull from the mmikeww repo. you would be pulling from mmikeww into andy, in order to keep andy up to date. this is the opposite process as normal PRs, as i will get to

when andy is up to date on github, then on your local machine, you should pull from andy github, into your local machine repo. at that point, all 3 repos should be identical: mmikeww, andy, local/andy

then you branch off of local/andy and do your work as mentioned in the previous post

when fix1 and fix2 are done, you would PUSH from your local machine, up to your github/andy repo. you can push multiple different branches, and have all those branches live on your personal github

git remote -v               # check where your remote endpoints are pointing to
                            # these are usually automatically set up when you initially clone from github
git push origin fix1        # push the fix1 branch up to your 'origin' endpoint which should be github/andy
git push origin fix2        # push the fix2 branch up to your 'origin' endpoint which should be github/andy

now on your github/andy fork, you will have both the fix1 and fix2 branches

and then you can create separate pull requests on the mmmikeww repo, to pull from github/andy/fix1 and github/andy/fix2

[mmikeww]

there are many tutorials. you should just google "git tutorial" and follow a few of them, either doc based or video based. here's a web based one i just found:

https://learngitbranching.js.org/?locale=en_US

[andymbody]

I have not read you posts fully yet. I will do that today. But the trouble i run into when reverting back to main for each fix is...

If I fix an issue # 1. Send a PR for that. All good. Revert back to main (before fix 1), fix issue # 2. Send a pull request for that. However, I have not tested to see if the fix for issue 2 breaks the fix for issue 1. Because when I revert back to main after submission of fix 1, fix 1 no longer exists when I start fix 2. So I can easily break fix 1 with fix 2 and not even know it. I need to test the combination of fix 1 and fix 2 together to be sure I haven't broken the first fix. Branches dont seem to allow you to test both fixes cumulatively when you are always reverting back to main that is still in a state before either fix has been merged.

Does this make sense?

How do you keep the fixes separated, but test both fixes together at the same time?

Another scenario would be...

I fix 1, then revert back to main to start fix 2. I fix 2. But when you combine fix 1 and 2 eventually, they don't play nice together. You won't know that until the merge happens and the combination of fix 1 and fix 2 introduce a new problem that didn't exist prior to fix 1 and fix 2 being implemented. Is this an acceptable scenario? To fix 1/2 which cause issue 3?

This has happened many times, but the only reason it doesn't show up after merge is because I have stacked the fixes on top of each other so I know how 2 affects 1. I can then fix 3 (introduced), before i submit cumulative fix for 1 and 2 but can only be submitted with fix 1 and 2 in the same PR since my branches have the two fixes stacked for testing purposes.

[mmikeww]

good question, which shows youre already thinking about it properly

typically, if you are certain that you are working on separate sections of the codebase in the two fixes, you should do this model:

fix1                    --O3
                       /
master          O1---O2
                       \
fix2                    --O4

that does not guarantee success. it is still possible for some regression to exist, and then when the 2nd fix PR attempts to be merged, the person doing to merge will find out that the tests fail, and then new commits will need to be added to fix2 branch to fix the tests. that is fine, and it may not be caught until merge time. or possibly the merger will forget to run the tests and auto merge the PR and then the codebase is temporarily broken. but that is the fault of the person doing the PR merge. and they should know to run the tests before hand, and then if the tests fail, you leave a comment to the PR author that the tests broke due to new changes in master, and the PR branch needs fixing. this is normal collab process

alternatively you could use this method

fix2                         --O4
                            /
fix1                    --O3
                       /
master          O1---O2

that way you are building on top of your existing fixes, and can keep the test suite up to date. the problem with this is, sometimes fix1 will have bigger issues, and it is not ready to merge, whereas fix2 is simpler and can be merged immediately. however, if it was branched like this, fix2 would INCLUDE fix1, and so we would be merging both or nothing. this is really inherently worse imo. there are cases where you would use this method, say if you were doing a big feature branch, and then fixing a bug that you find on that feature. thats how i think of this branch model

so i really think the first method is the better way

however, if you think your code is solid, you could attempt to pre-empt the process, and test your fixes before hand. git is pretty powerful and can accomodate a lot of things.

suppose you have this

fix1                    --O3
                       /
master          O1---O2
                       \
fix2                    --O4

you could do:

git checkout fix1
git checkout -b combine1and2
git cherry-pick O4           # in reality the commit hash will be a string like a2b548sda
# i forget if you will have to add+commit or if it will auto append the commit

then you will have this:

combine1and2                  --O4
                            /
fix1                    --O3
                       /
master          O1---O2
                       \
fix2                    --O4

here, commit O4 was copied and replayed on top of the fix1 branch. this new combine1and2 branch i would use just as a throwaway where you are only using it to run the tests to see if there are any regression errors. if there are, you can make new changes on top in this new branch, and rerun the tests, and if it works, either commit here and cherry pick back to fix2, or just dont commit, switch branchs whiles the files are saved and edited but not yet commit, switch to fix2 and then commit there and then delete the combined branch

however, my mind still kinda resists this, because we dont know if fix1 is fully complete yet. it might require more changes depending if the code reviewer is satisfied or not, so you might be doing unnecessary work. but its up to you if you think its worth it

[andymbody]

Ok... thanks for the detailed posts. They are hard to read on my phone, but i will read them thoroughly later. Thank you for you help.

[mmikeww]

I fix 1, then revert back to main to start fix 2. I fix 2. But when you combine fix 1 and 2 eventually, they don't play nice together. You won't know that until the merge happens and the combination of fix 1 and fix 2 introduce a new problem that didn't exist prior to fix 1 and fix 2 being implemented. Is this an acceptable scenario? To fix 1/2 which cause issue 3?

correct, this is the normal process. consider, there may be multiple people working on separate changes. you have the luxury that you are the sole person contributing at the moment. so you are aware of what you're working on, and how your fixes might interact

what if 2 separate people have chosen to work on 2 separate issues? its likely we will run into exactly this issue, where the changes in both PRs conflict with each other. there is no good way around it. it will just depend which change gets merged first, and then if the 2nd PR now breaks the test, it will be up to that 2nd person to fix his code to stay current

This has happened many times, but the only reason it doesn't show up after merge is because I have stacked the fixes on top of each other so I know how 2 affects 1. I can then fix 3 (introduced), before i submit cumulative fix for 1 and 2 but can only be submitted with fix 1 and 2 in the same PR since my branches have the two fixes stacked for testing purposes.

yeah this is definitely the inferior way to do it. but i totally get your reasoning. you could try that cherry-pick workflow that i gave an example of

also i want to note, these conflicts are more likely to happen when you are making wide swathing changes to the codebase. as mentioned in other comments, typically we want to make the smallest possible changes at a time. this make it easier for code reviewers, and also can avoid merge conflicts like this. sometimes you cant avoid it though

[andymbody]

correct, this is the normal process

Lol... now I know one of the contributors to bugs being introduce with system updates.

I'm pretty good at introducing those too. Just try not to let them be made public.

[mmikeww]

this is the importance of the testing suite

person1 working on fix1
person2 working on fix2

totally disconnected and unknown what parts of the code they are each working on

fix1 gets merged. then the reviewer is going to merge fix2. with no tests, how can he be sure nothing is broken? with the test suite, the reviewer simply has to run the tests, and if everything works, then the merge can be considered safe. if he forgets to run the tests, then the reviewer is at fault, not person2. of course, the newer workflow is to use "continuous integration" which automates the running of the test suites with every new merge

and yes we all introduce bugs. we try to fix the code as much as we can locally, before pushing the code publicly into our repo or into a pull request. but git allows us to tidy up our history and manipulate it, instead of having a folder looking like this:

mainprogram.ahk
mainprogram2.ahk
mainprogram_copy.ahk
mainprogram_copy2.ahk
mainprogram_copy_plus_bugfix.ahk

[andymbody]

Ok... I see your point about two people introducing working code until they are combined. So its unavoidable in that case. And since it can happen in that case, it should be acceptable from the same author.

Thank you for the example about building the temp branch for testing. I didn't know that could be done. The software i use doesn't offer that feature so I guess I will need to eliminate my hesitation with manual git commands/prompt.

Thanks again for holding my hand thru my learning curve. I appreciate you sharing your expertise.

[mmikeww]

I would think that most git wrapper softwares can create branches. Whether you use any branch for testing or real work is completely up to you. So as long as your software can let you create branches you should be good. But yeah id recommend learning the command line but there's many ways to skin the cat

…

On Tue, Oct 14, 2025, 12:55 PM andymbody ***@***.***> wrote: *andymbody* left a comment (mmikeww/AHK-v2-script-converter#391) <#391 (comment)> Ok... I see your point about two people introducing working code until they are combined. So its unavoidable in that case. And since it can happen in that case, it should be acceptable from the same author. Thank you for the example about building the temp branch for testing. I didn't know that could be done. The software i use doesn't offer that feature so I guess I will need to eliminate my hesitation with manual git commands/prompt. Thanks again for holding my hand thru my learning curve. I appreciate you sharing your expertise. — Reply to this email directly, view it on GitHub <#391 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOQBDCHZV7GRK2LMYSP3B33XUTG3AVCNFSM6AAAAACJDSK7BKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMBSHAYDOOJXHA> . You are receiving this because you commented.Message ID: ***@***.***>

[andymbody]

Now is a good time to figure it out while the repros are synced.

The software i am using is open source... sourceGit. It allows cherry picking so maybe I can use that to create test branches, yet leave original commits on their dedicated branches. I'm going to play with that to see if I can create a repeatable process for testing all commits on top of each other.

Initial tests seem to indicate that this allows separate commits on their own branch to be submitted for separate PRs but with the benefit of cherry picking those same commits into a Tester branch thats only function is for testing all changes cumulatively. That's what I'm looking for. So its the cherry pick feature that enables this strategy to work as desired.

Are there any "gotchs" that I should be aware of when using this method?

[andymbody]

@Banaanae Thank you for the merge!

[mmikeww]

also, i just want to mention, related to the above discussion, its very common that a PR branch might diverge from when the time it was originally developed, compared to the present time when new commits might have been added on top of master

fix1                    --O3
                       /
master          O1---O2
                       \
fix2                    --O4

lets say fix2 is reviewed and its a smaller change and easier to reason about so it gets merged first. we now have this:

fix1                    --O3
                       /
master          O1---O2-----O5
                       \    /
fix2                    --O4

this is the original problem talked about, where maybe the changes in fix2 has broken some tests in fix1. but its also common that other work was performed directly on master, or maybe even merged from other PRs not shown in the example graph. but master could look like this:

fix1                    --O3
                       /
master          O1---O2-----O5---O6
                       \    /
fix2                    --O4

now the fix1 branch is not only out of date from the fix2 changes on master, but also other new changes on master. and so before fix1 can be merged directly, either:
1.) the reviewer has to attempt the merge and then fix the potential conflicts himself, or better yet
2.) the contributor makes the changes necessary and adds new commits to fix1 to bring it up to date with master

1.) would end up looking like this, but requires the reviewer to fix the potential conflicts, and remember he might not be familiar with the changes, thats why 2.) is preferable. but here's what 1.) would look like:

fix1                    --O3----------
                       /              \
master          O1---O2-----O5---O6---O7
                       \    /
fix2                    --O4

for 2.) typically, how i like to do it is via a git rebase. that means all the commits in the branch will be replayed on top of the latest master commit. this will change the history and if you mess up when trying to fix the conflicts, you could potentially mess up your branches. but since its so easy in git to make new branches, you could do the rebase from a duplicate test branch:

git checkout fix1            # first move to fix1 branch because thats what we want to branch off of
git branch fix1copy           # another way to create a new branch rather than 'git checkout -b NEWBR'

fix1copy                --O3
                       /
fix1                   |--O3
                       /
master          O1---O2-----O5---O6
                       \    /
fix2                    --O4

then rebase which will replay the commits on top and prompt you if there are conflicts

git checkout fix1copy
git rebase master
# fix potential conflicts

fix1copy                             --O7
                                    /
fix1                    --O3       /
                       /          /
master          O1---O2-----O5---O6
                       \    /
fix2                    --O4

in this example, commit O7 is really just a copy of commit O3 with any potential conflicts now fixed. and you can be certain that its now including all the other changes that had been already previously merged into master. and if something went wrong in the rebase and the fix1copy branch is somehow messed up, you still can fallback on the original fix1 branch

now you didnt need to use the duplicate copy branch. you couldve just done the rebase directly from the original fix1 branch. but its very common for rebases to have conflicts and as a beginner you might mess it up so its cheap and easy to have a duplicate branch. then you'd need to clean up your duplicate and you could delete one and then push the other up to your github and then create a new PR from the new branch, or push the fix1copy changes up to the original PR branch, or whatever

the "fixing the conflicts" part is not trivial. many times you will run into broken tests or big changes that need to happen in order to make the rebase succeed, before that O7 rebase commit happens. you might fix enough of the conflicts just to get the rebase to succeed, but the O7 commit still is failing other tests, and then you'll need to fix those and maybe make O8, O9 commits etc to get that branch working fully

but this example is extremely extremely common when working on shared respositories with active development, so its very beneficial to get familiar with a workflow like this

[mmikeww]

sourceGit seems fairly comprehensive so i'm sure it will be able to do everything i mentioned here

[mmikeww]

this last long post that i made is actually my preferred way, rather than cherry-picking and doing that intermediate testing. because until the code is merged into master, you dont know if other changes might be needed to either of the branches. so in most cases, youd want to do a periodic rebase against master just to make sure your PR fixes are up to date with the current master. but definitely feel free to experiment with all of the methods. you will learn a lot by doing and visualizing the results

[andymbody]

Thank you very much for your time and effort to assist me with getting up to speed. This process reminds me of all the times I (we) have struggled with learning something new... very frustrating at first, then gets easier with practice, then becomes second nature, then using that knowledge to assist others as well (pay it forward). I really appreciate your patience and willingness to provide guidance. And even taking time to draw the ascii diagrams. I will experiment with the tools your have taught me. Thank you!

[andymbody]

That interactive tutorial is a good start for me. Good idea. Thanks. I did not realize that the navigation/manipulation around your branches/commits was so flexible. I also did not realize that Git really doesn't have that many commands to learn. That site covers a lot of them. Now I need to practice. Thank you!