suggestion: relaxed branch workflow with git based

[gcb]

Very hard to port stuff back and forth relaxed and master. Or even to verify.

One suggestion is to use git rebase instead of proper PRs. The advantages are

You can clearly see which (and more importantly on which commit) features are disabled from master, as all the disables commits will show up on top of the git log.

Updating is very easy if we always git rebase origin/master and force push on top of relaxed.

Very easy to keep up to date with master. Can even make CI build from master push an updated version of relaxed, as rebase after adding new lines on user.js should not cause conflict.

Worst case from above auto update, some features will not be disabled from master. Worse case now is that relaxed is too behind master with new settings and might be less secure.

The downsides are: 1. having to forcepush and 2. breaking the ability to submit changes from github web or desktop UI.

the workflow for maintainer would be

1. git checkout relaxed
2. edit user.js
3. commit new relaxing code
4. bring up to date with master: git rebase origin/master
5. force push relaxed :(

Steps 2-3 are optional and would obviously not happen on the master CI build.

To check/merge PRs from contributors into relaxed:

1. git checkout relaxed
2. git fetch origin pull/ID/head:BRANCHNAME
3. git cherry-pick COMMITID
4. force push relaxed :(
5. manually close PR :(

the endresult is that the gitlog will show (more recent to older):

1. re-enable service worker
2. re-enable history
3. etc...
4. merge PR#123 into master
5. from here on, is the regular master history... the merge above is literally the last merged PR on master.

[pyllyukko]

Hi.

Yes the relaxed branch is currently a bit problematic. Thanks for the suggestion.

• bring up to date with master: git rebase origin/master
• force push relaxed :(

I really don't like the idea of force push, as that is not a correct way to do things with Git IMO. Something should still be done regarding the relaxed branch to get it in line with master branch.

[nodiscc]

I maintain my own relaxed version (https://github.com/nodiscc/user.js/tree/dbu - master...nodiscc:dbu) and have no problems regularly merging @pyllyukko's master into this branch. No need for rebase/force-push.

[gcb]

The force push to a version branch is perfectly fine in some cases. linus et al use this same process in the kernel for some specialized architectures' branch. The relaxed branch is pretty much a tag that can receive PRs. the main difference in the end is that it saves you the merges back from master.

the end result is that instead of having:

x - master commit
x - master merge
x - relaxed commit
x - master merge
x - mixed master/relaxed history
...

you get:

x - relaxed commit
x - relaxed commit
x - relaxed commit
x - master HEAD
x - rest of master history
...

it makes it very very easy to use relaxed but enabled a few hardened features by removing some commits, or the other way around, to use master but cherry-pick a few one or two features you need to relax. Also make it very convenient to take a quick look at relaxed and see the changelog on top of master, which is invaluable to new comers trying to understand/decide. And it automatically keep both in sync by design (i.e. relaxed still points to tor-browser-52 instead of 68 in the makefile for something... i don't use that makefile so not sure)

[nodiscc]

Well I just had to rebase my branch because the history was beginning to get messy :) so I have no strong opinions about this. A rebased branch makes it easier to see exactly the changes from master, it makes it easy to cherry-pick so... why not.

The main problem in my opinion is that the relaxed branch is constantly lagging behind master and it has nothing to do with merging/rebasing - only some kind of automation can take care of merging master changes to relaxed. Maybe it would be better to maintain the "relaxed" settings as a set of patches in a directory? This way users can apply exactly those they want to their own user.js. See master...nodiscc:dbu for some examples

[rusty-snake]

. Maybe it would be better to maintain the "relaxed" settings as a set of patches in a directory?

Have you ever thought about a "relaxed.js" with is appended like a user-override.js in the ghacks-user.js?

[gcb]

The patch idea is great. Trying to write something even more specialized, using the comments on top of each setting block. But still not happy with the syntax. if I can't get anything out soon I will push a PR just to show it.

But basically, get rid of the branch, and have a "build" that generates a relaxed.js based on the comments on the mainline. So changes to add/remove things from relaxed are comments on top of the actual setting, and the history is a single one.

[nodiscc]

Proposed solution in #505