Suggestion: Pick a style guide for us to help clean up the code, without you having to stick to it yourself

[Jonta]

;comments like this
; comments like this

Reading through the current https://github.com/TaranVH/2nd-keyboard/blob/master/ALL_MULTIPLE_KEYBOARD_ASSIGNMENTS.ahk there are a whole bunch of different styles

I'd start submitting pull requests

But: Maybe you do have some preferences with regard to style, and that will lead to me wasting a bunch of time, and you feeling bad for me

Amazing features of picking a style guide:

• It doesn't have to cover every code case. Certainly not from the beginning. 50% is a whole lot better than 0%
• Not all code has to follow it. 80% is a whole lot better than 0% - Incremental progress
• Makes code easier to read, because internet strangers will make it easier to read for you
• The beautiful code attracts more code people, giving you more help, giving you more time to improve tree houses and trainplanes

There are a bunch of style guides out there, so if you're not picky, this one looks okay: https://github.com/aviaryan/Ahk-Best-Practices

[TaranVH]

This is a good idea and all, but I'm very afraid of letting other people "clean up the code" as you say.
Just allowing someone to create a readme.md, resulted in me having massive problems with ... I think it's called "pushing" ... my code onto github one time. Here I am struggling with it:
https://youtu.be/vRld4bVFrpU?t=262

And that's the second time that something has gone horribly wrong with me using github. The first time, I ended up nearly losing like a month of changes to my scripts because I did SOMETHING wrong when "syncing" with github, and it downloaded a lot of old code from github, and directly overwrote most of my .ahk files. Fortunately, Notepad++ still had them in memory, so I saved those newer copies of everything somewhere else, and then did a compare on every single pair, checking to see what the hell happened, and which changes were from other people, which changes were from me, and manually, miserably putting it all back together.

So what I do now, is if someone recommends a change on github, I'll just copy/paste it into my scripts. Code ONLY gets uploaded TO github. I have no idea how to safely download/sync/merge/pull/whatever-it's-called FROM github.

I think you underestimate just how much you know, and just how little I know!

I know it's sloppy, but it all currently WORKS, damn it, and many of my attempts to clean stuff up have resulted in miserable debugging sessions. I don't really have time to learn a lot of the stuff that I'd need to know to make this work.

So.... don't submit pull requests. I won't really know what to do with them. Or, again, I'll just copy/paste the code directly. But I won't do that if it's too complicated, requiring me to do a lot of testing to make sure it'll be okay. I don't know how this works! I could learn, but in my experience, there's always some goddamned edge case that comes up and screws up everything, and then the real programmers are like, "oh yeah well of COURSE it works like THAT, this ruined repo is your fault, LOL."

I do appreciate your comments, and will watch those videos you linked. Eventually.

[Jonta]

Alrighty

1. We grow Taran's knowledge of Git, and thereby his confidence in using it. Just like it happened with Adobe Premiere
2. I think what happened in the part of the video you linked to was this: You'd been making changes to the scripts, but not pushing them to GitHub. Perhaps not even committing them.

What dat mean?

1. You make file
2. You change file
3. You tell git about file (git add)
4. You change file. Lots of times.
5. But! Butt!
6. You should tell Git "Yo! Remember this change. I might wanna get back to it"
7. That's committing. git commit
8. And guess what: You've done that a bunch of times already! Last time was 3 weeks ago, with the commit-message "updates n things"
9. 2nd butt:
10. Changes are still just on your computer
11. Not on GitHub
12. :(
13. That's where git push comes in
14. :)
15. But before you push your changes onto the rest of the world, best to git pull first. You know: See what other people have been doing
16. You wouldn't want me to say "Hey Taran! I've improved your software! Here!" without me knowing what you've been doing for the past 6 days/weeks/months while I was off in a cave, catching spelling errors, right? Gotta get up to speed first.
17. And yes, when you pull, there might be merge conflicts: Sarah (the 3rd Butt of this episode) changed the same piece of the file that you did. She wants a headline to read "Welcome to Taran's Amazing Keyboardhacks", whereas you want it to read "Welcome to Taran's Overwhelming Keyboardhacks". That's alright. Your git client will show you both, and then you can choose.
18. And there won't be any overwriting of your local changes either, because you committed them
19. So after you've decided between "Overwhelming" and "Amazing" (maybe changing it to "Overwhelmingly Amazing"), you can push
20. There's also git stash, and branches, but I think we've come far enough for now

I've made a repo on my own account, for you to observe and experiment with: https://github.com/Jonta/Taran-should-trash-this

That way, you don't have to deal with the headache of explaining its existence to people coming here from e.g. YouTube

I'll have a look at GitHub's own GUI https://desktop.github.com/ - Unsure whether I can install it on the Windows-machine I have access to right now. Edit: Reason for me taking a look: To better know what to recommend to you

GitKraken has a nice visualisation of the tree, but only has a 7-day-free-trial

Walking on eggshells sucks, especially when those eggshells are so important to your life. We'll find the right spellbooks to turn those puny wooden eggs into stone, then iron, then diamond, and finally netherite