mio il primo tentativo di risolvere questo è il seguente:
git push --all -n 2>&1 | grep -q 'Everything up-to-date' ||
echo "Outstanding commits to be pushed at $PWD"
Non è robusto, come affermerà che ci sono delle uscite ing si commette sugli errori. Il problema più grande è che chiederà nome utente/password, ad esempio se si tenta di passare a un repo github con https-link (in genere perché ho fatto un checkout su alcuni repository in cui non dovrei spingere direttamente le modifiche).
La risposta di jtill sembra adattarsi al meglio, in quanto contiene istruzioni su come controllare questo per tutti i rami. Da qui il mio secondo tentativo assomiglia a questo:
git branch -avvv 2>&1 | grep -q ': ahead ' &&
echo "Outstanding commits to be pushed at $PWD"
Tuttavia, questo ha anche almeno un avvertimento - ci saranno falsi positivi se un messaggio di commit contiene la stringa ': avanti'.
Allora ho questo comando per "verificare lo stato di tutti i pronti contro termine Git":
for gitrepo in $(find ~ -name '.git')
do
cd $(dirname $gitrepo)
git fetch >/dev/null 2>&1 ||
echo "Git fetch failed at $PWD"
git branch -avvv 2>&1 | grep -q ': ahead ' &&
echo "Outstanding commits to be pushed at $PWD"
done
:-)
E 'davvero bisogno di essere up-to-date con il recupero? Ci verrebbe ancora detto che stiamo avendo commit senza spingere, non importa quanto sia cambiato il repository upstream ... l'unica eccezione che posso pensare è se uno spinge i changeset su un altro nodo, e poi spinge il changeset dall'altro nodo e upstream ... ora upstream è in sincronia con il repository locale, ma senza "fetch" non si saprebbe ... hm :-) – tobixen
@tobixen anche push forzato e ripristino dal backup. Se Murphy non sembra un innocente che salta attraverso i campi di margherite, non sono abbastanza paranoico. La versione informatica della legge è "se qualcosa può andare storto, è già andato male e vuole il tuo sangue". – jthill