How to (recursively) identify git repositories which could be updated, i.e., pulled (i.e., are out of date)

Question

I use many git-repositories to organize my work (>30), all of which are organized below a single root. (I do not use modules and I don't want to.)

My question is whether anybody could provide a simple script that goes through all subfolders recursively (some are git repositories others are not) to find out whether pulling would bring some changes. I.e., I do not want the script to do these pulls, I just want a list of folders (containing a git repository) that I could pull. (Obviously one "can" always pull; what I mean is that the remote repository has changes that were not pulled yet.) I believe that 'somehow' git fetch could provide this information, but I didn't figure out how since it seems that even executing it twice brings different results. And obviously I want my script to always lead to the same output as long as I don't pull any of its repositories, e.g., also when I execute it twice in a row.

(FYI, a related question was asked and answered here), but there they do actually want to execute those pulls, which I do not; I want to do this by hand in case there are conflicts etc.; I really just want the list.

Just FYI: The dual (complement) to this question is how to find/identify repositories in which I have local (rather than remote) changes. You find it here.

Answer 1

I just realized what git fetch is actually good for.^^

So all one needs to do is to fetch from all repositories. Calling git status afterwards will just tell us whether the current repository is behind the remote one.

So we can simply write the following function (or as an alias) to put into the .bashrc:

function gitoutdated()
{
find . -type d -iname '.git' -exec sh -c 'cd "${0}/../" && git fetch && git status | grep -q "is behind" && pwd' "{}" \;
}

There are a few ways how the script could be improved:

1. Currently, when calling it the first time, it also prints the output by the fetch commands, which seems distracting. One could possible pipe this away into nothing to get a clear list only. (We also see the clear list when calling the script a second time.) The same is true for repositories which don't exist anymore. Instead the list of those could be provided separately (this would however require a bit more coding effort).
2. One could also show how many commits one is behind, but I don't deem this important. Outdated is outdated! :)