If you have an issue comment / PR description on GitHub, it doesn't automatically get anchors / IDs that you could link to:
What I like to do is to add a visible #
character like this:
Active Backup for Business | |
Active Backup for G Suite | |
Active Backup for Office 365 | |
Antivirus by McAfee | |
Archiware P5 | |
Archiware Pure | |
Central Management System | |
Data Deposit Box | |
Synology Directory Server | |
Docker |
👋 Moved to https://github.com/borekb/docker-path-workaround
UPDATE 07/2018: I switched from Git Bash to MSYS2 recently which should be very similar, if not the same, but there some subtle differences which made me realize this is more tricky than I thought and that I don't 100% understand what is going on. If someone can help, please let me know in the comments.
Invoking docker
in MSYS2 shell or Git Bash typically fails with complains about paths, for example:
#!/bin/bash | |
# Merges child repo into target repo. Maintains branches and tags, filters history. | |
# | |
# Based on this amazing article: https://gofore.com/merge-multiple-git-repositories-one-retaining-history/ | |
#--------------------------------- | |
# Variables | |
#--------------------------------- |
First, take a look at the ESLint rule documentation. Just skim it for now. It's very long and boring. You can come back to it later.
ESLint rules works on the AST (Abstract Syntax Tree) representation of the code. In short, this is a tree structure that describes the code in a very verbose form. ESLint walks this tree and rules can subscribe to be notified when it hits a specific node type, like a Literal
type, which could be the "hello"
part of const welcome = "hello";
.
Go ahead and play around with some code in AST Explorer (Make sure the parser is espree
). It's a great tool!
Here are some good articles on the subject (ignore the scaffolding parts):
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
#!/bin/bash | |
# | |
# git-mv-with-history -- move/rename file or folder, with history. | |
# | |
# Moving a file in git doesn't track history, so the purpose of this | |
# utility is best explained from the kernel wiki: | |
# | |
# Git has a rename command git mv, but that is just for convenience. | |
# The effect is indistinguishable from removing the file and adding another | |
# with different name and the same content. |