The bug was in the RK808 PMIC, which may or may not be used on an RK3288 based system. It looks like the RK3288-based ChromeOS devices do use it though.
fastclone uses reference cloning, which references objects from another clone but pulls missing stuff from origin. There are two local object stores, the reference clone and the referenced clone. Cloning semantics are identical to a regular clone, it's just 'git fastclone' instead of 'git clone', presumably without some of the standard options like --reference, --shared, --shallow, etc.
worktree appears to do away with the extra complication; it's just another working tree off the same base clone. There's a single object store. You have two commands to deal with, 'git clone' and 'git worktree'.
I think that both can be used for the same purposes and yield similar results, but fastclone is targeted at the automated build scenario whereas worktree is more developer-focused. In an automated build environment with an m:n relationship between repos and builds, I think worktree would be more complicated because you'd have to handle the 'clone vs. worktree' decision yourself. It's also apparently not great w/ submodules yet; fastclone claims to handle submodules.
Fastclone is another attempt to deal with the distributed-ness of git in a scenario where you don't want or need local copies of the objects, just the working tree. We fight with this at my company; we like git, and it does some nice things, but our use case is really better suited to a centralized vcs. For people looking at fastclone, etc. - consider that maybe you don't really want a dvcs in the first place.
`local` is a bash-ism so it's best avoided in this context, and the command is running in its own shell anyway so the variables can't pollute anything else.
The variables can already exist in the environment. One of them is tested by a statement that is reachable without that variable being initialized in that script.
A fix that keeps the script POSIX would be to initialize the variable.
That's what the `--autostash` is for. It also has the advantage that the stash will be restored at the end of the rebase even if it hits problems and needs to be continued or aborted.
Note that this is only the Zigbee Light Link master key. A lot of devices use the Zigbee Home Automation specification which has a different well known master key (in that case it's in the standard which is freely available).
The ZLL key is slightly more interesting because you can factory reset (and effectively steal) devices in someone else's network, but that does require physical proximity to the device.
The master key also means that you can make your own device to add to someone's network. Most ZLL networks have a simple push button adding process, so you just need to be close to the button for a few seconds in order to add your own device to the network, after which you can control any other devices already in the network.
I always use "--no-ff" when merging topic branches to master. The advantage is that you can keep individual commits on the topic branch readable and still get an overview of the changes between two releases with "git log --first-parent".
You can also see the set of changes in a topic merge easily with "git log ${merge}^2..${merge}^1" whereas if you use a fast-forward merge it's not at all obvious which sets of commits are related.
