I have a website; some pages I maintain manually, some others, I generate using tools (mostly Shinx). For manually maintained pages, I'd like to migrate to Jekyll.
So my idea was to copy my whole website in a jekyll project, and progressively move pages from static HTML files to jekyll-managed markdown files, much easier to maintain. Generated pages, on the other hand, would be copied untouched.
It works pretty well... except that Jekyll does not copy the files starting with an underscore, which I have quite a lot: Sphinx names some special directories with a leading underscore (_static, _modules...), and I publish some python code, in which leading underscore are also used (e.g. __init__.py).
I know I could use the include directive in _config.yml, and add one by one all known files/directories that I want to keep. But I would still risk to miss some files (especially when my generators evolve).
I would rather be able to tell Jekyll, for each generated subdirectory, "this directory should be copied as-is". This would prevent it to look at every file in it to see if it should be processed, and so any file, starting with an underscore or not, would be blindly copied.
Is there a way to do that? I could not find any...
The strategy I use (and, I assume, the strategy intended by the jekyll developers) is to have the generation tool (sphinx, yard, ...) generate directly into the output directory (e.g. _site/api) and add the resulting folder to the keep_files configuration option in _config.yml
Jekyll copies any folders it finds, as is, unless their names begin with an underscore. An underscore tells Jekyll to not copy the directory to _sites directly.
As you are moving to Jekyll I'd say it's best to follow Jekyll's standard naming format and remove the underscores from directories that you do want copied to _sites.
This is odd. A folder named hippo_menus wasn't being included in my output. It used to, but then stopped all of sudden. I changed it to hippomenus and now it's included in the output.
Related
File templates for WebStorm can be placed in the config/fileTemplates directory of the local WebStorm settings folder.
In addition to the templates stored there, I have a couple of file templates for our project that are in the project SVN repository. I want WebStorm to also offer me these templates.
Is there a way to tell WebStorm to use a specific folder in my working copy on top of the usual fileTemplates directory?
I could find some hints, but they appear to be dead-ends (or maybe I'm missing something):
The documentation on sharing templates makes this sound very manual (as in, moving files around). This is not a viable approach, as the template files might be updated any time. I do not want to preemptively copy the files around after each of my daily working copy updates, just in case on of them has changed (nor do I want to watch out for changes to the templates folder - I want WebStorm to catch up on these udpates on its own).
The article on file and code templates refers to per-project templates that "can be shared among the team members". This sounds like the right thing, except that they have to be placed in the .idea folder (the folder with the project file(s)). As I'm working on a huge project with many submodules, each team member (of several dozen devs) is only interested in a different subset of the overall project, so everyone has their own .idea folder that is not committed to version control.
The article on project and IDE settings indicates that (only?) "Locations of the config, system, plugins directories can be modified in idea.properties file."
I have some files stored in a web server, which serves the files using apache like this:
Now, I'm planning to move all these folders to a GitLab repository, the problem is that GitLab is slow (please do not offer to use GitHub, I have certainly checked that alternative) and so I don't want to use GitLab's default way of showing files, instead, I want something similar as the apache way of showing files, as a static page, to use it as a GitLab page, so that I would be able to download and see the structure of my repo, but fast.
I wouldn't mind if I have to run a command to produce this static HTML page before each commit I make, but it would be cool to know that it exists, otherwise, I would have to create it (using python, for example), but of course, I would prefer an already created wheel instead of rediscover mine.
Thank you.
You could consider generating a page in markdown, with your Git repo (repository) structure content, and then publish it on the wiki side of your (here GitLab) project.
See "Is there a way to represent a directory tree in a Github README.md?" as an example, except you don't want to use your own repo README.md, but rather the wiki, in order to keep the repo and its representation (on wiki) independent
.
I use mercurial to keep track of a repository which contains both PDF files (generated by others, which I need to keep track of), and latex files, written by me.
For instance, assume a directory structure like this:
root
- Requirements.pdf
- MyReport.tex
- MyReport.pdf
In this case, MyReport.pdf changes every time MyReport.tex does, and can be wholly determined by the contents of the tex file, so it should not be under version control.
I am looking for a way to tell mercurial to ignore such files. Obviously I can add a rule to .hgignore like this (http://www.selenic.com/mercurial/hgignore.5.html)
syntax: glob
*.pdf
But that will ignore the PDFs that I do need to keep version controlled.
There's also this link: https://www.mercurial-scm.org/wiki/TipsAndTricks#Avoid_merging_autogenerated_.28binary.29_files_.28PDF.29 but that doesn't really solve my problem either, because while it handles building the PDFs, it does not handle telling hg which files are important.
Or I could just do this manually, but I would like a way to script it, to make it more general, since these repositories can have several dozen tex and pdf files and manually managing this has become cumbersome.
It seems like quite a simple rule: If there is a file by the name of "blah.pdf", check to see if there is also a file name "blah.tex" and if so, ignore it, otherwise, pay attention to it. But I can't find anything about that.
There is no such feature in Mercurial, nor in Git, nor will there likely ever be such a feature because it's extremely niche. However, you might consider simply putting your "generated" files into a separate output subdirectory, and then ignoring all such directories. For example, if you have an input like foo/bar.tex, the output could be foo/gen/bar.tex, and you could ignore gen/.
Obviously I can add a rule to .hgignore like this
(http://www.selenic.com/mercurial/hgignore.5.html) ... But that will
ignore the PDFs that I do need to keep version controlled.
.hgignore ignore all newly added or existing not versioned files, matching pattern, but bolded texts give you at least two usable solutions:
Write regexp, which means "all pdf, except some filename(s)" (with manually added filenames, most probably)
use wide pattern, but add needed files into repository explicitly (hg add FILENAME)
Is there an Mercurial extension that removes lines from .hgignore that aren't matching any files in the local repository.
There exists no extension or built in function that does this. You could jerry rig a script to do to find lines that are ignoring nothing without too much work, but consider that this is probably a bad idea.
Just because the .hgignore line isn't matching an files on your local repository doesn't mean it's not matching them on anyone else's repository. Within .hgignore files you'll often find patterns like .swp and .bak. You might not use vi (which creates .swp files) and you might not use an editor that creates '.bakfiles, but other do. Or perhaps your editor creates .swp files but you don't currently have any because you're not actively editing a file. Removing that line means you'd not be ignoring a .swp file next time you had one andhg addremove` would cause it to become tracked.
There are one or two files, like .hgignore, which I generally want to be the same in each of a bunch of projects.
However, the nature of these files means that I can't simply move them to a common shared project and just make the other projects depend on that project. They have to be inside each project. Symbolic links are not an option either because some of our developers use Windows.
How can I share these files between repositories and have changes propagated across (on my local machine, at least)? I'm using Eclipse.
For your specific case of hgignore you can put an entry like this in each project's .hg/hgrc file:
[ui]
ignore.common = ~/hgignore-common
If you you know your common library will always the in the parent directory, as is often the case with a subrepo setup you could do:
[ui]
ignore.common = ../hgignore-common
or if you know it will always be in a sibling directory of project checkouts you could do:
[ui]
ignore.common = ../company-wide-defaults/hgignore-common
Unforunately there's no absolute way to reference a file that's valid everywhere, but you can at least to to a point where on your machine all your checkouts are referencing a common ignore.
Hardlinking instead of copying the relevant files sort of works with Eclipse - although you have to refresh each of the other projects to get it to pick up the change. However, you can configure Eclipse to watch the filesystem and automatically refresh whenever it needs to - I recommend this.
It does not work by default with Emacs, because Emacs breaks hard links (which is normally the right thing to do, but is not what you want in this case). However, you can disable this behaviour for multiply-linked files with (setq backup-by-copying-when-linked t).