qw3rtman/git-fire

Could pushing to remote repositories do paralellized?

Xender opened this issue · 8 comments

Xender commented

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 commented

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 commented

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. :)

  • 👍3
jgkamat commented

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 commented

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 commented

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

Xender commented

@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"?

  • 👍1
qw3rtman commented

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?

  • 👍1
jgkamat commented

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

map117