Making Git retain different section content between branches

Question

I'm developing a Userscript that my employers have asked me to begin to manage via Git.

Right now, I have a stable file and a beta file, so that everyone in the organization can install the stable code but can choose to help test the beta additions instead, if they want. Some portions of that file should remain different, the content and changes should not be merged between branches.

For example, if I convert the Beta file to a Git Branch, and later decide that the Beta changes are stable and merge the Beta back into the Stable code (which will not have changed) the Git Merge process as I understand it will "helpfully" update the Stable Greasemonkey definition headers based on whatever values are on those lines in the Beta branch. This is thoroughly undesirable, as these headers contain an auto-update URL that Greasemonkey will check for updates.

// ==UserScript== (stable)
// @downloadURL  --  StableURL File Location
// ==/UserScript==

// ==UserScript== (beta)
// @downloadURL  --  BetaURL File Location
// ==/UserScript==

>Git Merge<

// ==UserScript== (stable)
// @downloadURL  --  BetaURL File Location
// ==/UserScript==

I want to retain the ability to have distinct URLs between the Beta code and the Stable code, but have not been able to identify a method to make Git's merge process ignore the lines that Greasemonkey needs to do its thing properly, but if I don't have the Beta as a separate Branch, I'm not sure how to use Git to easily migrate changed code from Beta to Stable, which is the stated reason for asking me to adopt Git functionality. (Well, the other reason is to make it easier for others to contribute to and identify the history of the project...)

Any help is much appreciated.

score 3 · Accepted Answer · answered Nov 20 '13 at 04:00

3

All your changes should be merged except changes to those values, which makes them not like the others, not changes to intrinsic content but deployment-specific changes. Those might be best applied in the post-checkout hook. Here's a sample, a per-branch include processor

cat <<\EOF >.git/hooks/post-checkout
#!/bin/sh
if branch=`git symbolic-ref HEAD --short -q`; then
    for file in `git ls-files -cix*.@branch`; do
        echo "* making ${file%.@branch} from $file with branch-specific includes"
        echo '/^@include-branch-specific ([a-z/]*)$/ { s//cat \1.'$branch'/e }' \
        | sed -rf- $file >${file%.@branch}
    done
fi
EOF
chmod +x .git/hooks/post-checkout

# testing
git checkout beta

cat  <<\EOF >config.@branch
// ==UserScript==
@include-branch-specific config
// ==/UserScript==
EOF

echo >config.stable '// @downloadURL  --  StableURL File Location'
echo >config.beta   '// @downloadURL  --  BetaURL File Location'

git add config.*
# git rm --cached config
git commit -m'setting up per-branch configs'
git checkout

git checkout stable
git cherry-pick beta
git checkout

answered Nov 20 '13 at 04:00

jthill

55,082
5
77
137

Yeah, once you get into it git just rocks. The best part here is that branch names are repo-local, you can test new configs for any deployment from any checkout without interference or interfering, with e.g. `git checkout -B stable`, do your tests, then `git checkout -t upstream/stable -B stable` to put it back. – jthill Nov 20 '13 at 14:35
@Steve (or `git checkout test` to use the original branch name for the current checkout, then `git branch -f stable upstream/stable` to put the stable ref back) – jthill Nov 20 '13 at 14:43
Once I have the config file from post-checkout, I presume that I would also be able to write another hook to insert/replace the appropriate header lines at the top of my actual code file based on the config file that this generates? Probably in pre-commit? – Steve Nov 20 '13 at 16:24
@Steve no, "config" is a nonce name, the tests show how to use the hook with your sample data assuming it's in a file named "config". Apply the same method to your real file. – jthill Nov 20 '13 at 23:01
You'll wind up with files something like `userscript.js.@branch`, `downloadURL.beta` `downloadURL.stable`, and the template will be exactly your current script except with `@include-branch-specific downloadURL` where lines that need to be branch-specific should go. – jthill Nov 20 '13 at 23:05
1

I just misunderstood the nature of the suggested change to my environment. This works wonderfully! – Steve Nov 21 '13 at 01:41

score 1 · Answer 2 · answered Nov 19 '13 at 20:21

In your repository, create three files, called header.master, header.branch and main.js. Then you can keep different versions of main.js in different branches, but keep the header files the same - one for each branch, and all header files will be in all branches.

Make a build script, called build.sh, which looks like this:

#! /bin/sh
cat header.$(git rev-parse --abbrev-ref HEAD) main.js >myscript.js

Either users must run your build script, or you must provide the prebuilt user script yourself - but I guess you are already doing the latter, since you have a download URL!

Thanks, this makes sense and looks like it should work, but is (as I expected) a solution that moves the problem outside of Git... — Steve, Nov 19 '13 at 20:41

score 1 · Answer 3 · answered Nov 19 '13 at 20:44

1

You could write a custom merge driver for git, and configure git to use it - but this would probably be more trouble than it's worth.

answered Nov 19 '13 at 20:44

Robin Green

32,079
16
104
187

score 1 · Answer 4 · answered Nov 19 '13 at 23:43

1

Delete the @downloadURL line from all files.

From the @downloadURL documentation, when the line is omitted, Greasemonkey will check the URL that the script was originally loaded from, for updates. The release users will update from the release location and the beta users will update from the beta location.

If a users wants to switch from one branch to another, he just deletes the script first and then loads from the appropriate branch.

Likewise, the scripts should not have an @updateURL line either.

answered Nov 19 '13 at 23:43

Brock Adams

90,639
22
233
295

That might be what GM docs say, but this has not been observed in the implementation of my project, likely because the files are being hosted internally on a server not recognized as "secure" by Greasemonkey. Sadly, the project has no control over the hosting location chosen for it, and must work with what is provided... The @downloadURL line was the only known way to provide any automated update support. (Also, the scripts are named differently to more easily differentiate between them if one has both installed but only one running. Ancillary to original question: solve one, solve both.) – Steve Nov 20 '13 at 03:19

Making Git retain different section content between branches

4 Answers4

Linked