Re: [Newbie] How to *actually* get rid of remote tracking branch?

[Jakub Narebski <jnareb@gmail.com>]

Sergei Organov wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Sergei Organov <osv@javad.com> wrote:
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>> Sergei Organov wrote:
>>>>
>>>>> I want to get rid of origin/pu remote tracking branch. What do I do?
>>>>> I RTFM git-branch. What does it suggest?
>>>>> 
>>>>> git branch -d -r origin/pu
>>>>> 
>>>>> So far so good. However, it doesn't seem to work in practice:

[...] 
>>>       fetch = +refs/heads/*:refs/remotes/origin/*
>>
>> [...] 
>>> Isn't "git branch -d -r" supposed to do whatever magic is required to
>>> get rid of the remote branch? Currently it seems like a bug introduced
>>> by addition of wildcards refspecs, right?
>>
>> No, the '-r' part translates 'pu' into 'refs/remotes/origin/pu', and
>> the '-d' option removes branch locally. It is meant I think to remove 
>> tracking of branches which were dropped in remote, as I think that 
>> wildcard refspec does create new branches, but do not delete dropped 
>> branches.
> 
> Isn't it 'git remote prune <name>' that is meant to remove tracking of
> branches which were dropped in remote?
> 
> Anyway, description of '-r' in man git-branch:
> 
> -r::
> 	List or delete (if used with -d) the remote-tracking branches.
> 
> Suggests it should be deleted. What's a point to delete it if it will be
> re-created on next fetch anyway?

Once more, with feeling.

By default now git creates on clone the configuration which essentially
says to fetch (get) all "proper" branches the remote has. (By "proper"
I mean branches residing under 'refs/heads/'). That is what the wildcard
spec above says.

Now when the remote repository dropped some branch (branch was deleted
on remote), te corresponding local tracking branch (in
'refs/remotes/origin') does not get deleted.

You can delete _all_ "stale" tracking branches, which means deleting
all tracking branches for which corresponding tracked branches were
deleted on remote. Or you can delete _one_ specified tracking branch
using "git branch -r -d".

Note that you told git to delete tracking branch, not to stop tracking
all branches in remote (as in above wildcard regexp), or stop tracking
some branch (the configuration earlier version of git created on clone,
without wildcard pathspec). So when you ask git to fetch from remote
again, it happily re-creates deleted branch. Note also that git *cannot*
distinguish (yet) between newly created branch on remote, and branch
which tracking branch you have deleted, either by accident or on purpose.

As to documentation: <tongue in cheek> if you cannot distinguish
between tracking branch and tracked branch then it is your damn fault
;-PPPP </tongue in cheek>


Analogy: if you delete file in working area (git branch -d -r), and
checkout again (git fetch), the file will be resurected.

>> So I'm not sure if it is a bug, misfeature or a feature.
>>
>> Can anyone better versed in wildcard refspecs speak up, please?
> 
> Yes, please!

I'm most interested if "fetch = !refs/heads/branch" or 
"fetch = -refs/heads/branch" works as a way to specify exclusions
from refspec.


P.S. Solution would be to use git-remote or ls-remote and some magic
to generate full list of refspecs instead of wildcard refspec.

P.P.S. We used to have similar problem with the introduction of
wildcard refspec, namely: which branch from all fetched to merge :-)
-- 
Jakub Narebski
Poland