Gitlab Markdown has support for references to files in the repository structure, like:
[README](doc/README)
or
[README](doc/README#L13)
But are there ways to reference files and lines in these files, but from a given commit, at least in the Wiki ?
Maybe something like:
[README](1ab3fa71:doc/README#L13)
or using the file hash id like:
[README](9a27b101#L13)
To use relative links from wiki to the repository (or wise versa) is not supported officially according to Gitlab's documentation (cited from v11.5, still valid for v15.3):
Note: Relative links do not allow referencing project files in a wiki page or wiki page in a project file. The reason for this is that, in GitLab, wiki is always a separate Git repository. For example, I'm a reference-style link will point the link to wikis/style when the link is inside of a wiki markdown file.
There is, however, a syntax which seems to work currently:
[[README|/../blob/1ab3fa71/doc/README#L13]]
But be aware: all text of the same paragraph will just be lost!
I work around that by phrasing like this, which renders like expected for Gitlab CE v11.3.0 at least:
Here you see xyz:
* [[README|/../blob/1ab3fa71/doc/README#L13]]
The root-anchored link (/../blob/<version>/<path-to-file>) ensures that it works from every Wiki page independently from their nesting depth.
For sure this syntax also works for branch names or any other relative link like /../tree/1ab3fa71/doc for example.
Maybe long after the battle, but I found a workaround : Simply make a link to a page where the README.md is. And that's it !
To get the link simply go to a page which displays the document, copy the URL, make a link to that address, append #L with the line number.
Exemple :
[Readme Pelargos](http://192.168.80.250:10080/project-root/android/Pelargos/blob/develop/README.md#L47)
One way I've found that, for the most part, works is to mouseover the line of code that you want to reference in the relevant file. While doing that, click the link icon that appears in the lefthand-side gutter to copy the line reference. With it copied, you then use a slightly revised version of the path in the copied URI.
Here is an example of a link copied using the gutter icon:
https://gitlab.com/settermjd/mezzio-sms-sender-api/-/blob/main/src/App/src/Handler/SMSReplyHandler.php#L23
This is the revised path that I used in a commit. Note the parent directory reference prior to main/:
/../main/src/App/src/Handler/SMSReplyHandler.php#L23
I realize that the file reference in the gitlab wiki, references files from the wiki repository itself and not from the project repository (source code repository).
However, when you make a reference to a hash, it knows if the hash refers to a commit or a file, so you can make references to a specific file from the project repository.
Related
Good day all, been reading the various docs at Gitlab and Asciidoc websites and I'm not seeing if there's a way to autofill a variable created in Gitlab that is included in the asciidoc it creates? For example, if I'm pushing code to my branch and it starts the Gitlab builder. I would like to take the author variable with my name in it and when the asciidoc that the builder generates, can I just put {author} for it to auto-fill my name in it?
Not 100% sure I'm understanding how this works exactly, any help would be greatly appreciated.
Thanks
If your Gitlab builder explicitly calls asciidoctor, you can define attributes using the -a flag. For example:
asciidoctor -a author="My Name" contents.adoc
Environment variables can be added in the same way:
asciidoctor -a author="My Name" -a path=$PATH contents.adoc
See the CLI Options page for other options that you can specify during asciidoctor invocation.
If the builder calls other actions that do the building, and you cannot access those actions, then this won't work.
Note that defining the page author is normally handled by including the name (and email address) immediately after the page title (before the first blank line). See the Using the Author Line page for details.
For example:
= Document
Author name
The standard Asciidoctor theme automatically displays the page author immediately after the page title.
For other attributes that are included in the document, or specified as page attributes, you'd need to include {attribute_name} within the page markup to see them.
I am trying to find the best way to document my project in Gitlab. And I found two different alternatives:
Markdown in the actual repository (my-repo.git)
Wiki using markdown (my-repo/wiki.git)
Note that the suffix .git indicates that these are two different git repositories.
I like the approach to simply modify the Wiki using markdown from the webpage (for everyones simplicity), but I am missing how to link between them or any other project in Gitlab.
In the documentation is provided some information to link (issues, commits, etc...) to other projects but not link files like the README.md and other documentation.
Is there such functionality?
I also don't know if I am 100% getting your question, but Gitlab does support special syntax for referencing other projects/commits/etc..
You can reference other project like so,
namespace/project>
It doesn't support referencing files in other projects (as far as I can tell), but you can reference files in the same project:
[README](doc/README.md)
And to specify a line number:
[README](doc/README.md#L13)
I don't know if I get your point to 100%.
Linking to other "files" is like links to any URL / URI in markdown. Use the "well-known" syntax [LinkName](LinkTarget).
A Link inside the same project
[Link to file, relative path](./README.md)
This should work in WIKIs and Project Markdown-files.
[Link to a file from other project](https://gitlab.com/{{USER or COMPANY}}/{{PROJECT}}/-/blob/master/{{FOLDER}}/README.md)
You can also use the reference syntax for links [LinkName][LinkReference] and then later in your file [LinkReference]: https://gitlab.com/foobar/123 when you want to reuse your links or collect them at the end of your file.
I'm using the Node.js version of TiddlyWiki, and I'd like to link to images on my filesystem.
The documentation listed here doesn't work; in the [img[path]] tag, for the path part I put something like /Users/documents/ken/path_to_image.jpg yet nothing shows up in the tiddler.
My wiki exists in /Users/documents/ken/wiki.
I know this is an old post, but zacts stated that you can use a macro plugin or simply use the [img] tag to point to the relative path of the image from the tiddlywiki.html file, but the op is using the node.js version, and zacts apparently didn't read that. There is no tiddlywiki.html file for TiddlyWiki on node.js. That only works with the static .html version of tiddlywiki, not the node.js version.
Currently there is no way to point to a local file through the node.js version of Tiddlywiki as node.js is not a webserver, therefore it does not see subfolders like /images/ off of the root url. The only way is to run a parallel web server on the same machine and use the full web url to the images served up from the web server.
In case someone else stumbles across this problem:
I could not find this documented anywhere, but what seems to work is to just copy the image in the tiddlers directory, then restart the nodejs server, and search for the image title from tiddlywiki. There will be a tiddler that contains that image, that you can edit at your leisure.
Alternatively, copy the image as image_name.png (or image_name.jpg) into the tiddlers directory, and create a image_name.png.meta text file with the following contents:
title: image_name
type: image/jpeg
Upon restart of the tiddlywiki nodejs server, a tiddler with title image_name which contains the image will be there.
If you are using the Node.js version, you can simply put it in the ./files folder, and then use [img[. /files/xxx.jpg]] to reference it.
I had this same issue recently, and I found a neat little solution for it. Let me send you the links, and I'll post the snippets here.
I happened to stumble across this tiddlywiki image gallery homepage that linked to a macro plugin that lets you link in local images. Here is the link to the tiddler for the plugin: http://www.richshumaker.com/tw5/tw-photo.html#External%20Image%20Path. Here is the original TiddlyWiki google groups post of the plugin for this: https://groups.google.com/forum/#!msg/tiddlywiki/ChRV6sjQpn4/bCm35_XhGmkJ.
I hope this helps! =) (note: when I get more time I may clean up the formatting of this post).
It is very simple, you use _canonical_uri field
_canonical_uri field
The field value is something like "./wiki/path_to_image.jpg" (mine is "./files") in the same level as the tiddlers folder. I did not experimented with files outside the root folder of the wiki. The dot in the path might be ommited.
The content type might be "audio/mp3" "image/jpg" look at the "parser" shadow tiddlers. Your Browser might support more content types like "audio/wav" but you would have to add this line to "$:/core/modules/parsers/audioparser.js" For example. Might be the same thing for images. Check your browser support.
I really do not know why this fact is so obscure, but it work wonders.
I wanted to download Linux kernel module source code from http://lxr.free-electrons.com/source/net/bluetooth/. Is there any tool like SVN to download the source code generated by LXR engine?
Thanks in advance!
If you're still looking for an answer, here is a procedure based on a low documented feature of LXR.
Display the file you are interested in
Modify the URL in the browser address bar, adding at the end ?_raw=1 and go there (i.e. press return key)
The file is then displayed "as is", without any decoration (it is sent as text/plain)
You can now save the file from browser menu command File->Save as
NOTES:
The ?_raw=1 argument can be used to have HTML files interpreted by your browser, i.e. displayed as HTML because they will be sent as text/html.
The feature has been present in LXR for ages, though in versions older than 0.10 the argument is spelled ?raw=1 (without underscore).
I checked that ?raw=1 works with free-electrons though they use 0.3.1 which was released in 2003!
The documentation on lxr states that there is a git repo.
http://lxr.linux.no/
I have never tried it, but it may be what you are looking for
Not exactly an answer, but I was looking for a related thing - the possibility to download individual C files from LXR as plain text. If it was possible to download files as text, in principle you could write some sort of a parser/automatic downloader for a whole directory.
The documentation for the LXR engine seems to be here:
LXR Cross Referencer - Browse /doc at SourceForge.net
... and as far as I could see from the 1.0 PDF manual (note that lxr.free-electrons.com seems to run on version 0.3.1, though), there is no mention of plain-text source files being exported (in addition) to the HTML.
So, very likely, as the plain-text source files seem not to be available in an LXR export, there will be no tool that will be able to download. (Btw, I too wish there was a tool like this, otherwise the only option is to clone the entire Linux source tree via git).
Note, however, that there is also an experimental version of LXR from lxr.linux.no ; that one generates HTML that requires JavaScript, and it will show a "download" button in its interface; then one can download the plain-text source file. As lxr.linux.no is down for me for the moment, here's a link to an annotated HTML page to another site, that seems to use the same engine (there is no note ATM for the LXR engine numeric version):
http://lxr.missinglinkelectronics.com/#linux+v2.6.38/sound/drivers/dummy.c
... and this is how the link looks like to obtain plain-text version:
http://lxr.missinglinkelectronics.com/linux+v2.6.38/+save=sound/drivers/dummy.c
Note that this is a different URL format than what lxr.free-electrons.com would use:
http://lxr.free-electrons.com/source/sound/drivers/dummy.c?v=2.6.38
... and there is a note on the start page ( http://lxr.missinglinkelectronics.com/ )
once you enable JavaScript, which states that:
lxr.missinglinkelectronics.com is currently running an experimental fork of the LXR software provided by lxr.linux.no.
... or, in other words: the link format for downloading plain-text source files from lxr.linux.no, will not work for the (current) lxr.free-electrons.com installation.
Here you can browse the references and also can download the source file
https://code-grep.com/view/project/54b083273b2082684a000008/linux-3.19-rc2
On free-electrons.com, it works by adding the argument "raw=1" in the URL. For example, this URL...
http://lxr.free-electrons.com/source/drivers/misc/lis3lv02d/lis3lv02d.c?v=3.8
... will become this :
http://lxr.free-electrons.com/source/drivers/misc/lis3lv02d/lis3lv02d.c?v=3.8&raw=1
The resulting page can then be saved using the "file saving" feature of your browser. On Linux and Windows, this is usually mapped to the ctrl+s keyboard shortcut.
I have an existing site in a path, and I've pointed the DreamWeaver site to it.
Under \templates there is a master.dwt file. But whenever I save this file, none of the html files which should make use of it change. What do I need to do to get DW to update the html files that make use of it? And how does DW know which files should be updated based on the template changing? Does it use an internal store or something because every time I copy the site to another machine, I'll need to link up all the pages to the relevant templates again.
I've tried going into Modify | Templates | Apply, but no templates are listed. I have a .dwt file in the path so why isn't it picking it up??
There's several possible issues in play here:
For Dreamweaver to properly recognize the existence of the template, the folder in the root of the site should be Templates and not templates.
Once Dreamweaver "sees" the Template properly you then need to make sure that the proper code is present in the child HTML files so Dreamweaver knows which files to update via the template. This code takes the form of HTML comments scattered throughout the page. You will always have the following line after the <html> tag:
<!-- InstanceBegin template="/Templates/TemplateName.dwt" codeOutsideHTMLIsLocked="false" -->
After that, editable regions are delineated with code that will look like this:
<!-- InstanceBeginEditable name="someregion" -->
stuff you can edit
<!-- InstanceEndEditable -->
Without the above, the child pages will not respond to the template.
Now for the real bad news. Unless the existing pages match up with the template exactly, you are going to have all kinds of problems getting the template to play nicely with the existing content. Doing Modify | Template | Apply Template to the page when the page is already fully formed will generate a dialog box that asks you map the content to the editable regions in the template. But if the rest of the design elements vary from what the template contains, Dreamweaver will preserve those tags alongside what the template will introduce which usually creates a ton of duplicated tags and broken layouts.
You would be FAR better off creating new, blank pages from the Dreamweaver Template and copy/pasting the contents into the editable area and then overwriting the "old" pages with the Save As command.
I just encountered this issue myself. I realize this original question was posted some time ago, but for anyone who might encounter this problem in the future, I am posting my solution.
If the only changes made to the template relate to one or more elements contained in an attached/linked file (such as a CSS style sheet or JS file), which changes Dreamweaver allows directly from the .dwt template itself, using the style boxes at the side/bottom, then Dreamweaver does not perceive any change to the actual .dwt file itself. If you want those changes to "take effect" and apply them to all pages, you might type a change to the .dwt file itself, click "save all" - undo the change and click "save all" again. This step is really not entirely necessary, as the changes to dependent files can be affected to the website by putting the dependent file to the website.
Also, Dreamweaver will apply changes to CSS/JS dependent files, across the board, but may continue to use a cache, until closed and reopened.