They are remote tracking, we create them as remotes for code review  
and testing. Once we are satisfied we rebase and merge to testing,  
then delete the remote tracking branch so the I'll effects of history  
rewriting are never present.

The side effect is that the deletion of that origin only affects the  
origin repo itself and the developer who deleted the remote branch.  
Everybody else still has this spurious record of origin/foo where  
origin/foo no longer exists.

So I was hoping there was an esoteric command that would go out check  
what's really valid and remove the invalid ones from the local repo.

On Oct 13, 2009, at 6:30 AM, "Michael P. Soulier" < 
 > wrote:

> On 12/10/09 donnoman said:
>> Our team creates topic branches, then when they are ready rebases  
>> them
>> and merges them into our testing branch and then deletes the old  
>> topic
>> branch.
>> Apparently git pull and fetch don't automatically trim the list of
>> branches that it thinks origin has.
>> On my local checkout a branch -a shows 20 or so branches that have
>> since been deleted, but I can't get them to go away.
>> Is there any facility to force it to go out and verify it's list
>> against the real origin, instead of deleting the whole checkout and
>> recloning?
> git branch -d -r name
> You're talking about remote tracking branches?
> Also, one should not rebase a branch that has been made publically  
> available.
> Mike
> -- 
> Michael P. Soulier <>
> "Any intelligent fool can make things bigger and more complex... It
> takes a touch of genius - and a lot of courage to move in the opposite
> direction." --Albert Einstein

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to