About the official site (ahkscript.org)

[fincs]

I wasnt aware forum software had entered the subject

Oh. Guess I misunderstood guest3456's sentence & tried to shoehorn that into the discussion. Nevermind then.

[guest3456]

I'm (in principle) in favour of moving the ahkscript.org content to GitHub pages (in fact, it was even planned by poly for the old domain). However, documentation should be set up strictly using submodules - otherwise it would be a mess (with 4 kinds of documentation in the same repo and the impossibility to use git merges) & would destroy git history.

I have just been offering suggestions. I don't care either way. It seems that submodules do not automatically update, so each time Lex updates his docs repo, the ahkscript repo would need to be updated to point to the newer commit.

I don't know if it would be a mess to include everything in one repo or not. But yes it would mess up the git history.

Things that indeed need to be considered are the downloads and the forum (amongst other "services"). They could get their own subdomains which would still be hosted using the current ahkscript server (download.ahkscript.org and boards.ahkscript.org) and we could set up redirects from the old locations (if that's even possible, otherwise it's a major show-stopper). Additionally, in the case we recover the autohotkey.com domain, this would make it easier for us to merge.

Yes the actual download files need to be considered where they will be hosted. Probably at the current webserver, just like the forums.

If we're considering the possibility of changing the forum software

Yeah, I wasn't suggesting this at all. And anyway I'm not a fan of the Q&A type format ala stackoverflow or discourse

[fincs]

It seems that submodules do not automatically update, so each time Lex updates his docs repo, the ahkscript repo would need to be updated to point to the newer commit.

Well, Lexikos uses this little tool called "AutoHotkey" to do all necessary tasks (git pushing, file uploading, etc) when he publishes an update. He has already stated that he has no problem adding lines to his release script to update git submodules.

[guest3456]

Well, Lexikos uses this little tool called "AutoHotkey" to do all necessary tasks (git pushing, file uploading, etc) when he publishes an update. He has already stated that he has no problem adding lines to his release script to update git submodules.

Heh. He mentioned a 'release script'. What about when the docs update mid-release? Suppose someone makes a fix and issues a pull request and Lexikos accepts it. The docs repo will now be futher ahead than the linked submodule commit, until the next trigger of the 'release script' or until someone manually updates it. Any time Lexikos accepts a pull request, the submodule would need to be updated to the latest commit.

Then this same problem would occur with the external German and Chinese repos as well.

I don't care really. I say lets just make a choice and get started. Once its in place we can always iterate a change later

[lexikos]

Perhaps we can set up a script on this server to update the sub-modules. I believe git hooks could then be used to make GitHub trigger our script when someone pushes some new commits. Or maybe it could all be done on GitHub's side; I'm not sure.

About the downloads, I just noticed Releases on GitHub.

[guest3456]

It does look like github has an API to allow us to do these things.

Perhaps we can set up a script on this server to update the sub-modules. I believe git hooks could then be used to make GitHub trigger our script when someone pushes some new commits. Or maybe it could all be done on GitHub's side; I'm not sure.

It looks like in git 1.8.2, submodules can now track a branch instead of a particular commit. However, it seems a git submodule update --remote command is still needed to pull in the latest commit.

I believe we can monitor when the docs repo gets a new commit by setting up a webhook for the push event.

But I've searched for half an hour and can't seem to find out how to automatically update the submodule on github. Its pissing me off how little information there is.

About the downloads, I just noticed Releases on GitHub.

Perfect. I always git tag -a v0.5 my releases in my personal repos for quick testing in previous versions (git checkout v0.5).

From the github API:

1. Create a release
2. Upload a release asset

Even the release script itself could be put on github (minus the oauth credentials obv)

[joedf]

Just a quick recap of which parts that are going to be "affected"... Basically everything except the forum?

[fincs]

There is no evidence it is necessary to update the master repo when a branch-tracking submodule is updated for GitHub Pages to kick in (especially since we don't use Jekyll). git submodule update --remote is only used when you have a local clone of the master repo and you want to ensure that you are using the latest commit of each submodule. No file in the master repo is updated AFAIU.

EDIT: Confirmed.

Code: Select all

[submodule "v1"]
	path = v1
	url = https://github.com/Lexikos/AutoHotkey_L-Docs.git
	branch = master
[submodule "v2"]
	path = v2
	url = https://github.com/Lexikos/AutoHotkey_L-Docs.git
	branch = v2

EDIT2: Apparently not. Turns out branch-tracking submodules are just a wrapper around manually checking out stuff when updating submodules (so that a single submodule update command is necessary). Disregard this post then, it is still necessary to create a script to update the master repo.

[guest3456]

Yeah. I looked this up for a while last night.

[lexikos]

But I've searched for half an hour and can't seem to find out how to automatically update the submodule on github.

In theory, we can have a script on a web server somewhere which creates a tree containing the submodule update, then create a commit from it.

However, I'm not sure whether we also need to pull down the latest commits from the documentation repo and then push back up to the webpage repo. That would require being able to run git on the web server rather than just a PHP (or whatever) script.

[guest3456]

However, I'm not sure whether we also need to pull down the latest commits from the documentation repo and then push back up to the webpage repo. That would require being able to run git on the web server rather than just a PHP (or whatever) script.

No I don't believe we need to go that far. As far as I understand it, the webhook will callback to our php script when the push event occurs. According to those docs, the push event will contain the HEAD commit sha anyway from the docs repo. Then we just need to use this sha to update the submodule in our website repo.

But I've searched for half an hour and can't seem to find out how to automatically update the submodule on github.

In theory, we can have a script on a web server somewhere which creates a tree containing the submodule update, then create a commit from it.

I have no idea how the internals of git work as far as trees and blobs go so maybe you're right. This page says:

As an example, if you wanted to commit a change to a file in your repository, you would:

• get the current commit object
• retrieve the tree it points to
• retrieve the content of the blob object that tree has for that particular file path
• change the content somehow and post a new blob object with that new content, getting a blob SHA back
• post a new tree object with that file path pointer replaced with your new blob SHA getting a tree SHA back
• create a new commit object with the current commit SHA as the parent and the new tree SHA, getting a commit SHA back
• update the reference of your branch to point to the new commit SHA