In T117167#1794796, @Spage wrote:

1 .

I think line numbers are a useful way to specify a snippet. The wiki editor should use them with an unchanging commit (otherwise the file contents change)

First case: One idea is that we don't update these snippets as they are coming from a fixed commit (not from master) hence we don't need any update mechanism for these types of cases.
Second case: If we need to update them as this is the motto of the project then I am not sure how to find a simple and safe solution to update such snippets. I tried to use one in my previous project proposal as:

Idea is to maintain a mapping/database of source (git-doc), destination (wiki-page), commit-id (from which the content is taken), start line number (The start line number from where the content was pulled) and end line number (The end line number till where content was pulled). After any commit in the corresponding file, check the difference between the content of git-doc between the start line and end line of commit-id (saved in mapping) and the content of git-doc between start line and end line patterns in the most recent commit.
( Why patterns? : It might be the case that start line and end line numbers get modified after the most recent commit. By comparing the content using the line numbers might give a false information. Hence, the solution is to search for the pattern, which are present at git-doc' start line and at end line (for the saved commit-id in mapping), in the most recent commit.)
If a difference is reported by above comparison then previously saved commit-id, start line and end line will be replaced by present commit-id, start line and end line number.

But it uses a database and a complex approach.
Which one is good to proceed with?
2 .

Your step 2.

Idea is to maintain a mapping/database of source (git-doc) and destination (wiki-page) and adding a post commit hook which triggers the update remotely from Jenkins.

is interesting. If the wikipage is pulling in HEAD, then depending on caching the page will remain the same even when git updates. I don't know how much caching the parser cache and page cache do. If it's only cached for a day or so and editors can force new contents with ?action=purge, then maybe we don't need this complicated dependency handling.

Thanks, @Spage :)
Updated.

Now, script handles the tabs too. It searches for the tabs and replaces with four spaces.

As I haven't written any code which uses these tags (nowiki, pre etc.) hence, sorry for asking naive questions.

return array( $output, 'nowiki' => false, 'noparse' => true, 'isHTML' => false );

Will it work for text files also? Will nowiki => false not mess with text files?

Please clarify the time zone for the hours in the profile.

there should be some instructions in a comment at the beginning of the file ("place this script in the doc/ directory of MediaWiki and run it" or something like that).

So, are we planning to place the script in core?

IMO the preamble would be more readable if even empty lines were commented out.

I have edited the script to comment out the empty lines. But as discussed here tabs need to be converted to spaces in hooks.txt. Hence, I will upload the hooks.yaml after I get updated hooks.txt.
Should I submit a patch for updated hooks.txt or wait for one?

It can provide source code to the <source> tag or parser function to transclude highlighted source code into the page.

Here is the script for this task P2218 and corresponding yaml file

I have written a PHP script which coverts a text file in a yaml format. Please find the attached hooks.yaml (

So, first I should start working on T114719: Convert Git2Pages to use extension registration? Thanks.

I find this project very interesting and like to propose for the Outreachy internship program. What would be the next step?
Do I need to do the second step "create a new Phabricator task for your proposal" as mentioned on https://www.mediawiki.org/wiki/Outreachy/Round_11#Candidates . Thanks.