parallelization?

[brianbrownton]

This may be reaching a bit, but is it possible to modify this so I can run it in multiple ttys in parallel? Sometimes while doing updates there will be a slow downloading file (5-10 mins) which kind of halts my other cask updates due to the bottleneck. If I open a new terminal and run the script again, I will inevitably get a PR with multiple commits and other weirdness.

I understand that this probably not a problem that anyone other than myself experiences, and I have other work arounds. I would even be willing to try and submit a PR if there was some guidance around what to change. Presumably there is a hardcoded git checkout path for the new branch, which if it was variable each time the script ran would avoid this issue?

[vitorgalvao]

We could do it, but I doubt it’d be worth it. One way to go about it:

1. When cding into the directory of the cask to change, check the branch.
2. If master, proceed as usual.
3. If the branch name starts with ${cask_repair_branch_prefix}, git clone the repo in a temporary directory, cd into that and start at 1.

But the git clone will itself take a while. Simpler way:

1. After figuring out the cask’s repo, cp -r that into a temporary directory.
2. cd to the temporary directory and continue as usual.

It’d take a lot more disk space, but nothing a reboot wouldn’t get rid of.

[commitay]

A rather extreme solution that would let you do this without any changes to cask-repair is multiple installs of brew.

Installation.md#multiple-installations