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

From: Andreas Ericsson <[email-masked]>
Date: Tue, 13 Nov 2007 21:01:02 +0100

Steffen Prohaska wrote:
> 
> On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
> 
>> Sergei Organov <[email-masked]> wrote:
>>> Jakub Narebski <[email-masked]> 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:
>> [...]
>>>>> $ git branch -d -r origin/pu
>>>>> Deleted remote branch origin/pu.
>>>>> $ git remote show origin
>>>>> * remote origin
>>>>>   URL: git://git.kernel.org/pub/scm/git/git.git
>>>>>   Remote branch(es) merged with 'git pull' while on branch master
>>>>>     master
>>>>>   New remote branches (next fetch will store in remotes/origin)
>>>>>     pu
>>>>>   ^^^^^^^^^^^^^^^^^^^ What???
>>>>>   Tracked remote branches
>>>>>     html maint man master next todo
>>>>
>>>> Check out what do you have in .git/config file, in the
>>>> [remote "origin"] section. Most probably (if you cloned this
>>>> repository using new enough git) you have wildcard refspec there,
>>>> which means that git would pick all new branches when
>>>> fetching / pulling from given repository.
>>>
>>> Sure, I've cloned git.git using rather recent git, so .git/config has:
>>>
>>>       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.
> 
> "git remote prune origin" should be used to clean up stale
> remote-tracking branches.
> 
> BTW, what's the right name for this type of branch.
> I found "tracking branch", "remote tracking branch", and
> "remote-tracking branch" in the manual. The glossary only
> mentions "tracking branch".  Or is it a "tracked remote branch"
> as the output of "git remote show" suggests.  I remember,
> there was a lengthy discussion on this issue.  Does someone
> remember the conclusion?
> 

It seems we agreed to disagree. However, a "tracked remote branch"
is definitely not in your local repo. I think remote-tracking branch
grammatically is the most correct, as that's the only non-ambiguous
form (remote tracking branch might mean "remote tracking-branch" or
"remote-tracking branch"). It's also the only form that works when
used with "local" in front of it. "Tracked remote branch" will
always be a "remote branch", no matter how you prefix it.

I hate that part of git nomenclature with a passion. It's ambiguous
at best and, as a consequence, downright wrong for some uses.

> 
>> So I'm not sure if it is a bug, misfeature or a feature.
> 
> It doesn't make sense to delete remote-tracking branches
> locally if they are still present at the remote.  The main
> purpose of a remote-tracking branch is to be identical to the
> real remote branch.
> 

Yes, but it does make sense to say "I no longer want to track that
remote branch". If that should be implied by the user deleting its
local counterpart is, I think, what this discussion is about.

-- 
Andreas Ericsson                   [email-masked]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231