Emphasize "Not Secure"

[Madis0]

Uses a hidden about:config setting.

Also, sorry about the commit mess, I forgot not to push to upstream right away and slightly messed up later. (3917e013aed002792690d41ad99747827a6030a8 7d48ebbb3b8e8dd02e737527a284951fc8000b42 13337c6bc965e7e6ab241a50f2e40e0a99a64efd)

[Timvde]

Please also never use non-fast-forward merges. You can force that by executing git config merge.ff only in your UserChrome-Tweaks repository. Since this repository has been way less active in the past two months or so and no-one new seems to have cloned this repo in the meantime, I removed the last few commits.

I also see that you have pushed to the Firefox59 branch. You should also never do that. Development happens on master (well, on feature branches, that get merged into master). If you want to backport a feature to another version, please cherry-pick it from master. I also reverted your commit on the Firefox59 branch (which is why this PR got automatically closed, there is no commit left to merge). You basically should always still use the old workflow: create a branch in your own fork, then open a pull request here. The only extra power that I granted you, is merging pull requests of other people, and preferably only with the "Squash and merge" option.

[Timvde]

I enabled branch protection on master, so you shouldn't be able to push directly to that branch anymore. As a side effect, you should now explicitly approve a PR before you can merge it (but you should have the right permissions for that).

[Madis0]

By fast forward you mean: always do one commit per pull request? Alright, I can do that.

I didn't understand about the cherry-picking though, what if I create a CSS file for a newer/older version than master?

[Timvde]

By fast forward you mean: always do one commit per pull request?

No, it's git terminology. This is the difference between a non-fast-forward merge (left) and a fast-forward merge (right). The latter one gives a much cleaner history. If you always use pull requests and the "Squash and merge" option, you don't have to worry about this.

I didn't understand about the cherry-picking though, what if I create a CSS file for a newer/older version than master?

The easiest way if you don't want to get too much into git stuff is probably just creating the same PR on the other branch. If you do want to get into git stuff: cherry-picking basically means "apply this commit onto the current branch". So to get commit with hash abc123 on master to the Firefox59 branch, you could do this:

git checkout Firefox59
git pull --rebase
git cherry-pick abc123
git push

[Madis0]

The easiest way if you don't want to get too much into git stuff is probably just creating the same PR on the other branch.

I understand what you mean, but not what the goal is. If I create a style that is incompatible with current Firefox version, why push it to master at all?

[Madis0]

Okay, I think I get it now. You want master to be the development branch, that contains the latest of any CSS file. The other branches are supposed to reflect the latest files that work with them (but seem to be abandoned instead, unfortunately).

[Timvde]

You want master to be the development branch, that contains the latest of any CSS file. The other branches are supposed to reflect the latest files that work with them

Correct.

but seem to be abandoned instead, unfortunately

No. In that case, only create a PR for that branch and ignore master. Sorry, I didn't consider that case before. What I meant was: only push directly to a branch tracking a specific version (as opposed to master, which tracks Nightly), if it's a cherry-pick from master (and already has been approved there). In all other cases (or if you want, also in that case), create a separate PR for that branch.

Was this clear now? :)