Template talk:Repo link
Supporting different protocols
Specifically for git:// - which will help centralize all repo URLs - e.g. to replace all URLs with a corresponding template, instead of having git://git.code.sf.net/p/flightgear/simgear
everywhere - we should probably introduce a proto
parameter that defaults to http/https and which can be overridden so that "git" can be specified. We want to avoid having to manually update all related articles in the future (if/when another repository needs to be moved) - e.g. [1].
--Hooray (talk) 17:10, 4 April 2015 (EDT)
- Sorry that I do not understand you, but do you mean the URL in the template or URLs spread out in articles literally?
- —Johan G (Talk | contribs) 18:34, 4 April 2015 (EDT)
- the latter - currently, we cannot use either of those templates to update the "building FG" docs accordingly, many of which contain now wrong links to the repositories - especially those using the git protocol - so it would be better to either have 3 templates, or one parameterized template returning the requested repository URL, including the proper format - so that we can use {{SimGear repo|proto=git}} or something like that. Otherwise, we will have to update dozens of references manually whenever there's a similar change (thanks for your recent changes though!). Just imagine, repositories would have to change again some time soon - we would have to manually update all URLs again. So let's better use a template for such things, analogous to how the "Next Newsletter" template serves as a "pointer" and can be easily changed, without having to update any locations using it. --Hooray (talk) 18:48, 4 April 2015 (EDT)
- Ah, I think I get it now. In other words {{repo link}} is just as much maintenance as having bare URLs, but if adding more specific links, like your {{SimGear repo}} example the maintenance would more or less be only changing that template.
- If so that is one case where a definitively see a meta template used by other link templates as useful. The repo specific templates would in this context use {{repo link}} to simplify them.
- Repo specific links could also be more tailored to their needs, for example possibly using unnamed parameters for the parameters that are more or less always used (in essence less typing, I'm a lazy dude ;-) and have parameters more relevant to the context, for example {{FGAddon repo | B-1B | Systems/b1b-autopilot.xml | rev=3}}.
- correct, I am basically thinking along the lines of using/generalizing existing templates to generalize our "hard-coded" (for the lack of a better term) repository URLs in pretty much all wiki articles - so that updating repository URLs in the future will be mainly a matter of changing 2-3 templates. Which is why I suggested to also add support for different protocols, so that those templates can also be used for instructions on cloning/pulling using non-default (non-http) protocols. This would also allow us to introduce meta templates for document clone/update/pull instructions using a single template for different front-ends - possibly even including annotated screen shots. We kinda started preparing this a while ago by introducing templates like these:
- * http://wiki.flightgear.org/Template:Git_clone
- * http://wiki.flightgear.org/Template:Git_checkout
- * http://wiki.flightgear.org/Template:Git_push
- Once we adapt the new repo link template, we could easily use that for also maintaining everything easily. And the corresponding clone/checkout/push and pull templates could also contain instructions for different front-ends (think git command line vs. TortoiseGit), to help generalize our docs, especially for people on Windows/Mac OSX not as familiar with CLI environments.--Hooray (talk) 12:59, 5 April 2015 (EDT)
Also see the two build server related edits below:
- http://wiki.flightgear.org/index.php?title=Building_using_CMake_-_Windows&curid=7578&diff=85567&oldid=82460
- http://wiki.flightgear.org/index.php?title=Building_using_CMake_-_Windows&curid=7578&diff=85568&oldid=85567
We should ideally come up with templates for encapsulating such things, so that there's only a single place that needs to be maintained/edited if/whenever such URLs change.--Hooray (talk) 11:25, 16 June 2015 (EDT)
FlightGear has completed the move from Gitorious
FlightGear has completely moved all its gitorious based material over to< sourceforge. But it's nice to know a historical record will remain at gitorious.org as well as several other public locations not to mention on a myriad of personal computers.
— Curtis Olson (2015-04-15). [Flightgear-devel] Fwd: Gitorious.org is dead,
long live Gitorious.org.
(powered by Instant-Cquotes) |
Copied from this edit.
—Johan G (Talk | contribs) 10:54, 18 April 2015 (EDT)
Todo list
Note These proposals are out of date. See subsequent discussion instead. |
A list to record changes to repository link templates. Feel free to contribute.
Templates:
- Meta-template: {{Repo link}}
- Sub-templates
- {{Source repo}}
- {{Simgear repo}}
- {{Fgdata repo}}
- {{Aircraft repo}}
Arguments
Parameter name | Description | Type |
---|---|---|
Link modifiers | ||
site |
Specifies the site to link to | Mandatory |
proj |
Project name | Mandatory |
type |
Type of repo | Optional |
brt |
Branch, revision, or tag | Optional |
path |
Path to file | Optional |
lines |
Line(s) to link to | Optional |
subdom |
Subdomain of gitorious.org | Optional |
view |
View | Optional |
proto |
Protocol | Optional |
Label modifiers | ||
text |
Text to use as label | Optional |
pre |
Text to replace project name | Optional |
link |
Return plain-text link | Optional |
plain |
No formatting on link | Optional |
Link styles
- {{Repo link}}
- Normal
- flightgear/flightgear/src/Scripting/NasalSys.cxx (SourceForge)
- No path
- flightgear/flightgear/master (SourceForge)
- Download link
- flightgear/flightgear/archive/master.zip (SourceForge)
- Pre arg
- FG source/src/Scripting/NasalSys.cxx (SourceForge)
- Plain
- flightgear/flightgear/src/Scripting/NasalSys.cxx
- Protocol
- RO (read-only)
- git://git.code.sf.net/p/flightgear/flightgear
- http
- http://git.code.sf.net/p/flightgear/flightgear
- RO (read-only)
- Normal
- The following discussion got more general and was moved to FlightGear wiki:Village pump#Repository link templates (perm).
rss/feed mode
I was going to add a "feed" template for the simgear/flightgear and fgdata/fgaddon repositories, to link to the RSS feed for each in the main page, but I guess it would be better to extend/generalize this template accordingly? I am referring to these rss feeds:
- http://sourceforge.net/p/flightgear/simgear/feed
- http://sourceforge.net/p/flightgear/flightgear/feed
- http://sourceforge.net/p/flightgear/fgdata/feed
- http://sourceforge.net/p/flightgear/fgaddon/feed
The basic idea being to add another box to the main page to track recent developments (commmits). But maybe we could also add a corresponding mediawiki extension to parse/process those feeds directly, but I guess that would need to be discussed with Gijs or Simon ?
Any thoughts/opinions ? --Hooray (talk) 15:22, 9 October 2015 (EDT)
- I was not really aware of those. A start could be to make those as separate templates first and only then look for the common denominators and possibly a meta template (I guess mostly for common styling). Maybe they can be called {{x feed}}, {{x feed link}} or something like that.
- I guess the bigger part of your question is what to display and how. Just a box with a link would be easy. I am not sure how one would make them render in a box though, which seem to be what you would prefer.
- If they would be rendered in a box I think the developer portal is a better place than the main page. ;-)
SourceForge overhaul
I might try to overhaul the entire SourceForge section of the template to support all of the web interface. I might also look at supporting the non-web interfaces as well, and links to forks (the /u/ user pages as well as the project /p/ pages). The aim is to be able to use this template to simplify all of the subtemplates {{repo link/doc related}}.
Bugman (talk) 06:44, 24 February 2016 (EST)
- Note that this should probably only cover template related work, but not the corresponding edits to adopt your templates - Gijs has sufficient privileges to run wikimedia bots here, and he's done that in the past - most of those are typically written in Python, and can be easily used to update a bunch of articles in a single run, i.e. if we can come up with heuristics (e.g. regex) to update existing URLs, we can much more easily adopt templates elsewhere/everywhere. If in doubt, get in touch with Gijs --Hooray (talk) 07:07, 24 February 2016 (EST)
The overhaul is complete. We can now specify SourceForge web URLs, SCM commands, web-based files, branches, commits, tags, etc., and any imaginable combination using this template. New subtemplates using this master template, such as {{fgmeta file}}, are in progress.
Bugman (talk) 08:11, 25 February 2016 (EST)
Archived Gitorious overhaul
After the migration to archive.org, the Gitorious links have changed from:
To:
I propose to update the template appropriately. Note that line ranges can no longer be specified.
Bugman (talk) 08:07, 25 February 2016 (EST)
- My interpretation of the archived Gitorious infrastructure, which seems to now be web-only (I haven't worked out how to check out the repositories), is the following translation:
- https://gitorious.org/fg/hoorays-fgdata/source/topics/scriptable-ai-submodule:Nasal/ai/ai.nas?a=blob;f=Nasal/ai/ai.nas;hb=refs/heads/topics/scriptable-ai-submodule#l1
- https://<site>/<proj>/<repo>/source/<branch>:<path>?a=<view>;f=<path>;hb=refs/heads/<branch>#l<lines>
- I will redesign the Gitorious interface for this template based on this. Hooray, if you could provide as many new gitorious.org links to your code as possible, that would be much appreciated. I would like to fill out the Template:repo link#Gitorious examples (depreciated) section with as many different types of link as can be found.
- FWIWI, regarding "cloning", the website specifically says "We've done our best to not break clone urls. " at https://gitorious.org/ Hooray (talk) 12:46, 26 February 2016 (EST)
- I had some bad URLs :) Just needed to append '.git' to everything, and now I can clone ok. I'll create some 'git clone' examples, such as for looking at the history of the old fgdata.
topic/foo branch specification ?
Referring to [2] Why is this needed ? --Hooray (talk) 13:53, 16 November 2020 (EST)
- Wow, that's stretching my memory. I guess you mean the
/~
needed at the end of SourceForge branches. I think that I was going to implement the proper URL construction with/~
, but the logic required evaded me and I never completed it. The problem is documented in {{repo link}}, specifically in the parameter help description. E.g.:
For SourceForge git repositories, if the character
/
is present in the branch name, the text/~
must be appended to the branch.
- I'm not sure if MediaWiki allows us to detect if a certain character is present in a template parameter value. Again from distant memory, I think I asked for an extension to be installed to enable this to be implemented, but it never was. This is not a simple problem! Hence I took the shortcut of using the above text in the documentation.