The order of multiple remote.xx.fetch is significant for some operations

Someone asked me how to remove obsolete topgit feature branches from
the remote topgit controlled git repo. I found we can not run
"git fetch --prune" directly to delete stale remote branches from
local, because of the wrong order of multiple "remote.XX.fetch" config
variable.

For example, config variables for remote "origin":

    [remote "origin"]
          fetch = +refs/heads/*:refs/remotes/origin/*
          url = git@github.com:ossxp-com/topgit.git
          fetch = +refs/top-bases/*:refs/remotes/origin/top-bases/*

When running "git fetch --prune", will check all local refs, and delete
stale remote branches from local if their conterparts do not exist in
remote repo. But in this case, all remote branches under
"refs/remotes/origin/top-bases/" namespace will be deleted, even their
remote conterparts "refs/top-bases/*" still exist in remote repo.

How does this happen? e.g. a local ref:
"refs/remotes/origin/top-bases/t/featureX"

 * First make a reverse look up according to the remote.origin.fetch
   config variables;

 * The first remote.origin.fetch matches, and this local ref is mapped
   as "refs/heads/top-bases/t/featureX";

 * The remote repo does not have ref "refs/heads/top-bases/t/featureX",
   (it should be "refs/top-bases/t/featureX"), then this local refs is
   deleted as a stale remote branch.

 * While if we change the order of remote.origin.fetch config variables,
   The result is different. This local ref will map to
   "refs/top-bases/t/featureX", and won't be deleted.

So, it's not a bug of git, but a flaw of user generated config variables.
The hacks for Topgit are simple, see:

 * https://github.com/ossxp-com/topgit/blob/master/debian/patches/t/delete-remote-branch.diff
 * https://github.com/ossxp-com/topgit/blob/master/debian/patches/t/prune-stale-remote-branch.diff

--
Jiang Xin