Could pushing to remote repositories do paralellized?

[Xender]

When having multiple remotes, waiting for all while pushes are going out sequentially seems to be very bad idea in case of fire.
(Well, taking a time to run this script in case of real fire might be a bad idea in itself).

If one of the remotes is not responsive, it will delay pushes to others, and if one remote shows a password prompt, then the whole thing is blocked...

[qw3rtman]

In this case, wouldn't it just be best to push to one of the remotes (preferably the default)?

That way the code is at least in one remote and no one is waiting for all the remotes to be pushed to while they are being burned alive.

[Xender]

Well, if someone insist on really running this script before leaving in case of fire, may that person just run it and leave without waiting for completion.

In this case, parallel pushing would just increase chances of commits being pushed anywhere even if some remote earlier in the list blocks. :)

[jgkamat]

To be honest, probably the best thing to do would be to push a patch file to pastebin, and email a link to a few of the most recent committers. Or maybe just grab your computer 😄

Paralellizing this would be weird, as the user would get multiple password prompts? It dosent make too much sense. Most people have SSH keys set up w/o decryption passwords, but for those of use with decryption passwords/HTTPS remotes, this would break everything completely.

[jgkamat]

Also keep in mind, the 'most used' remote might be on the same computer, so that might not be much help. We want the most used remote online? How about

if $(git remote | grep -qo origin); do
  git push origin <branch>
else
  echo "You're screwed"
fi

[petersohn]

@Xender You mean that this script should be fire-and-forget?

[Xender]

@petersohn - Yup, unless you like some roasted programmers for dinner... :)

On the other hand, will this script comply with strict policies like "whoever makes a mess in the repo gets fired"?

[qw3rtman]

With paralellization, the remotes with a password would just be left at the prompt while the other remotes would be pushed to. This ensures that the code is pushed everywhere it can be pushed without involving any (unsafe) human interaction after firing the command, so I think it would be the best route to take.

@Xender, could you submit a PR with paralellization implemented?

[jgkamat]

You would need a clever way to wait for input when possible. When I try running pushes in paralell, the old secure pushes fail from not being in interactive mode.

As is, this is sort of useless, because the only unauthenticated remotes in reality are the ones on your own filesystem.

You could implement a heirarchy though (run local in parallel) -> (run ssh in series) -> (run https in series)

The first two are local remotes (on the same drive) and the second two are secured with SSH Keys