threads / discuss / 10845

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

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

## tl;dr

28 messages between Nov 13, 2007 and Nov 19, 2007.

replies: 27people: 9as markdown or json

Sergei Organov· Nov 13, 2007, 14:25 UTC · lore
Hello,

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 --version
git version 1.5.3.4
$ 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
  Tracked remote branches
    html maint man master next pu todo
$ 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
$ git fetch
remote: Generating pack...
remote: Done counting 422 objects.
Result has 281 objects.
remote: Deltifying 281 objects...
remote:  100% (281/281) done
Indexing 281 objects...
remote: Total 281 (delta 206), reused 255 (delta 181)
 100% (281/281) done
Resolving 206 deltas...
 100% (206/206) done
63 objects were added to complete this thin pack.
* refs/remotes/origin/pu: storing branch 'pu' of git://git.kernel.org/pub/scm/git/git
  commit: fc07419
$ 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
  Tracked remote branches
    html maint man master next pu todo
$
... and I get those origin/pu back?!
What do I do wrong?
-- 
Sergei.
Jakub Narebski· Nov 13, 2007, 14:53 UTC · re: Sergei Organov · lore

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

[Cc: Sergei Organov <osv@javad.com>, git@vger.kernel.org] Please CC git mailing list, git@vger.kernel.org

Sergei Organov wrote:
Show 8 quoted lines
> Hello,
> 
> 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:
Show 12 quoted lines
> $ 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. The wildcard refspec is not documented adequately, so I'm not sure if adding

        fetch = !refs/heads/pu

would help, or do you have to replace wildcard refspec by explicit list of branches you want to fetch.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Sergei Organov· Nov 13, 2007, 15:39 UTC · re: Jakub Narebski · lore

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

Jakub Narebski <jnareb@gmail.com> writes:
Show 32 quoted lines
> [Cc: Sergei Organov <osv@javad.com>, git@vger.kernel.org]
> Please CC git mailing list, git@vger.kernel.org
>
> Sergei Organov wrote:
>
>> Hello,
>> 
>> 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/*
Show 7 quoted lines
> The wildcard refspec is not documented adequately, so I'm not sure if
> adding
>
>         fetch = !refs/heads/pu
>
> would help, or do you have to replace wildcard refspec by explicit list of
> branches you want to fetch.

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?

-- 
Sergei.
Johannes Schindelin· Nov 13, 2007, 16:01 UTC · re: Sergei Organov · lore

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

Hi,
On Tue, 13 Nov 2007, Sergei Organov wrote:
Show 12 quoted lines
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > The wildcard refspec is not documented adequately, so I'm not sure if 
> > adding
> >
> >         fetch = !refs/heads/pu
> >
> > would help, or do you have to replace wildcard refspec by explicit 
> > list of branches you want to fetch.
> 
> Isn't "git branch -d -r" supposed to do whatever magic is required to
> get rid of the remote branch?
But it did!  You explicitely fetched it _again_!

Ciao, Dscho

Sergei Organov· Nov 13, 2007, 17:31 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 18 quoted lines
> Hi,
>
> On Tue, 13 Nov 2007, Sergei Organov wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>> 
>> > The wildcard refspec is not documented adequately, so I'm not sure if 
>> > adding
>> >
>> >         fetch = !refs/heads/pu
>> >
>> > would help, or do you have to replace wildcard refspec by explicit 
>> > list of branches you want to fetch.
>> 
>> Isn't "git branch -d -r" supposed to do whatever magic is required to
>> get rid of the remote branch?
>
> But it did!  You explicitely fetched it _again_!
Sorry, but *I* didn't *explicitly* fetch it _again_!
1. I cloned git.git repo making no custom steps.
2. I decided I don't need to track some of branches.
3. I tried to find in documentation a way to remove remote tracking
   branch. I found that 'git branch -d -r' should do it.
4. I used 'git branch -d -r origin/pu' to remove one of remote branches,
   -- it succeeded.
5. Some time later I ran 'git fetch', and it's *git fetch* that
   *implicitly* fetched it _again_! When I say *implicitly* I mean that
   I did nothing to tell 'fetch' to re-create the remote branch.

Please try to look at it from the *user* POV. A poor user that has no idea how all this is implemented internally and tries to use git documentation to do things.

-- 
Sergei.
Johannes Schindelin· Nov 13, 2007, 18:21 UTC · re: Sergei Organov · lore

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

Hi,
On Tue, 13 Nov 2007, Sergei Organov wrote:
> Sorry, but *I* didn't *explicitly* fetch it _again_!
> 
> 1. I cloned git.git repo making no custom steps.

Which means that you wanted to track that repository. Yes, the complete repository. Not a single branch. Not all branches except a single one.

> 2. I decided I don't need to track some of branches.

The you should have done that. But that is different from "I decided to delete the tracking _branch_".

Ciao, Dscho

Sergei Organov· Nov 13, 2007, 18:44 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 14 quoted lines
> Hi,
>
> On Tue, 13 Nov 2007, Sergei Organov wrote:
>
>> Sorry, but *I* didn't *explicitly* fetch it _again_!
>> 
>> 1. I cloned git.git repo making no custom steps.
>
> Which means that you wanted to track that repository.  Yes, the complete 
> repository.  Not a single branch.  Not all branches except a single one.
>
>> 2. I decided I don't need to track some of branches.
>
> The you should have done that.

I think I did my best to try to do that (basing my attempts on current git documentation). Isn't it?

> But that is different from "I decided to delete the tracking
> _branch_".

Yes, but the question is *why*? Isn't it an obvious application of deleting tracking branch? And, as I've already asked in another sub-thread of this one, what the following example in the man git-branch is supposed to achieve?:

<quote Documentation/git-branch.txt> Delete unneeded branch:: + ------------ $ git clone git://git.kernel.org/.../git.git my.git $ cd my.git $ git branch -d -r origin/todo origin/html origin/man <1> $ git branch -D test <2> ------------ + <1> Delete remote-tracking branches "todo", "html", "man" </quote>

Sorry, but I still believe that it's not me who needs fixing.
-- 
Sergei.
Jan Hudec· Nov 17, 2007, 16:56 UTC · re: Sergei Organov · lore

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

On Tue, Nov 13, 2007 at 21:44:11 +0300, Sergei Organov wrote:
Show 25 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Hi,
> >
> > On Tue, 13 Nov 2007, Sergei Organov wrote:
> >
> >> Sorry, but *I* didn't *explicitly* fetch it _again_!
> >> 
> >> 1. I cloned git.git repo making no custom steps.
> >
> > Which means that you wanted to track that repository.  Yes, the complete 
> > repository.  Not a single branch.  Not all branches except a single one.
> >
> >> 2. I decided I don't need to track some of branches.
> >
> > The you should have done that.
> 
> I think I did my best to try to do that (basing my attempts on current
> git documentation). Isn't it?
> 
> > But that is different from "I decided to delete the tracking
> > _branch_".
> 
> Yes, but the question is *why*? Isn't it an obvious application of
> deleting tracking branch?

No, it's not. Fetching has to bring you any heads that were newly created in the remote repo. It can't tell whether a head is new since last fetch or you just for whatever reason didn't have the tracking branch before.

Show 18 quoted lines
> And, as I've already asked in another
> sub-thread of this one, what the following example in the man git-branch
> is supposed to achieve?:
> 
> <quote Documentation/git-branch.txt>
> Delete unneeded branch::
> +
> ------------
> $ git clone git://git.kernel.org/.../git.git my.git
> $ cd my.git
> $ git branch -d -r origin/todo origin/html origin/man   <1>
> $ git branch -D test                                    <2>
> ------------
> +
> <1> Delete remote-tracking branches "todo", "html", "man"
> </quote>
> 
> Sorry, but I still believe that it's not me who needs fixing.

That documentation is precise. But it could maybe contain a footnote saying, that if you remove a tracking branch, next fetch will create it again unless you reconfigure it not to.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>
Jakub Narebski· Nov 13, 2007, 16:03 UTC · re: Sergei Organov · lore

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

Sergei Organov <osv@javad.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Sergei Organov wrote:
Show 6 quoted lines
>>> 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:
[...]
Show 22 quoted lines
>>> $ 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.

So I'm not sure if it is a bug, misfeature or a feature.
Can anyone better versed in wildcard refspecs speak up, please?
-- 
Jakub Narebski
Poland
Steffen Prohaska· Nov 13, 2007, 17:16 UTC · re: Jakub Narebski · lore

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

On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
Show 47 quoted lines
> 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:
> [...]
>>>> $ 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?

> 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.

In my opinion its a misfeature. "git remote prune" does the same in a sane way.

	Steffen
Jakub Narebski· Nov 13, 2007, 17:42 UTC · re: Steffen Prohaska · lore

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

Steffen Prohaska wrote:
> On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
>> Sergei Organov <osv@javad.com> wrote:
Show 12 quoted lines
>>> 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.

"git remote prune <name>" deletes _all_ stale tracking branches under <name>. With "git branch -d -r <branch>" you can delete _single_ tracking branch.

Show 6 quoted lines
>> 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.

True, but it would be nice to have an option to _exclude_ some branches from fetching (for example 'html' and 'man' branches of git.git), while still picking up new branches automatically on fetch.

-- 
Jakub Narebski
Poland
osv@javad.com· Nov 13, 2007, 17:58 UTC · re: Jakub Narebski · lore

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

Jakub Narebski <jnareb@gmail.com> writes:
Show 32 quoted lines
> Steffen Prohaska wrote:
>> On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
>>> Sergei Organov <osv@javad.com> wrote:
>
>>>> 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.
>
> "git remote prune <name>" deletes _all_ stale tracking branches
> under <name>. With "git branch -d -r <branch>" you can delete
> _single_ tracking branch.
>
>>> 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.
>
> True, but it would be nice to have an option to _exclude_ some
> branches from fetching (for example 'html' and 'man' branches
> of git.git), while still picking up new branches automatically
> on fetch.

Guys, could you please read man git-branch? What do you think this example is doing?:

<quote Documentation/git-branch.txt> Delete unneeded branch:: + ------------ $ git clone git://git.kernel.org/.../git.git my.git $ cd my.git $ git branch -d -r origin/todo origin/html origin/man <1> $ git branch -D test <2> ------------ + <1> Delete remote-tracking branches "todo", "html", "man" </quote>

That's *exactly* what I did! And it *doesn't work*! Well, it does delete the branches, but they are automagically re-created on the next fetch, so "deleting" them this way is useless.

-- 
Sergei.
Lars Hjemli· Nov 13, 2007, 18:17 UTC · re: osv@javad.com · lore

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

On Nov 13, 2007 6:58 PM,  <osv@javad.com> wrote:
Show 13 quoted lines
> Jakub Narebski <jnareb@gmail.com> writes:
> > Steffen Prohaska wrote:
> >> 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.
> >
> > True, but it would be nice to have an option to _exclude_ some
> > branches from fetching (for example 'html' and 'man' branches
> > of git.git), while still picking up new branches automatically
> > on fetch.
>
> Guys, could you please read man git-branch?

I understand that the man-page could be confusing, the problem is that these examples are quite old: they made more sense when git didn't support wildcards in refspecs.

You want an easy way to tell git to stop tracking the pu-branch. This can be achieved by editing the [remote "origin"] section in .git/config: remove the fetch-line containing refs/heads/* and add one fetch line for each ref you'd like to track. But beware that you have to add any new branches which you would like to track in the same way (editing .git/config).

The reason git-branch -d -r doesn't do this automatically is probably that nobody has seen a need for it to do so...

-- larsh

Sergei Organov· Nov 13, 2007, 18:59 UTC · re: Lars Hjemli · lore

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

"Lars Hjemli" <hjemli@gmail.com> writes:
Show 18 quoted lines
> On Nov 13, 2007 6:58 PM,  <osv@javad.com> wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> > Steffen Prohaska wrote:
>> >> 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.
>> >
>> > True, but it would be nice to have an option to _exclude_ some
>> > branches from fetching (for example 'html' and 'man' branches
>> > of git.git), while still picking up new branches automatically
>> > on fetch.
>>
>> Guys, could you please read man git-branch?
>
> I understand that the man-page could be confusing, the problem is that
> these examples are quite old: they made more sense when git didn't
> support wildcards in refspecs.

Yeah, I understand that. But there doesn't seem to be actual reason not to support them even with wildcards support.

Show 6 quoted lines
> You want an easy way to tell git to stop tracking the pu-branch. This
> can be achieved by editing the [remote "origin"] section in
> .git/config: remove the fetch-line containing refs/heads/* and add one
> fetch line for each ref you'd like to track. But beware that you have
> to add any new branches which you would like to track in the same way
> (editing .git/config).

Thanks, I got it. Though the last sentence makes it less useful then it should be. [This somewhat reminds me CVS problems when you can delete directories that you don't want, and checkout won't restore them (without special switch), but then you won't automatically get new directories :( Though admittedly the situation with the remote-tracking branches is less annoying.]

>
> The reason git-branch -d -r doesn't do this automatically is probably
> that nobody has seen a need for it to do so...

Me thinks it has probably been just overlooked when wildcards were added. Anyway, either documentation or git-branch -d -r should be fixed, I think.

-- 
Sergei.
Steffen Prohaska· Nov 13, 2007, 18:39 UTC · re: osv@javad.com · lore

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

On Nov 13, 2007, at 6:58 PM, <osv@javad.com> <osv@javad.com> wrote:
Show 32 quoted lines
>>>> 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.
>>
>> True, but it would be nice to have an option to _exclude_ some
>> branches from fetching (for example 'html' and 'man' branches
>> of git.git), while still picking up new branches automatically
>> on fetch.
>
> Guys, could you please read man git-branch? What do you think this
> example is doing?:
>
> <quote Documentation/git-branch.txt>
> Delete unneeded branch::
> +
> ------------
> $ git clone git://git.kernel.org/.../git.git my.git
> $ cd my.git
> $ git branch -d -r origin/todo origin/html origin/man   <1>
> $ git branch -D test                                    <2>
> ------------
> +
> <1> Delete remote-tracking branches "todo", "html", "man"
> </quote>
>
> That's *exactly* what I did! And it *doesn't work*! Well, it does  
> delete
> the branches, but they are automagically re-created on the next fetch,
> so "deleting" them this way is useless.
Yes, it is useless. The man page should be fixed.
	Steffen
Jan Hudec· Nov 17, 2007, 19:12 UTC · re: osv@javad.com · lore

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

On Tue, Nov 13, 2007 at 20:58:20 +0300, osv@javad.com wrote:
Show 19 quoted lines
> Guys, could you please read man git-branch? What do you think this
> example is doing?:
> 
> <quote Documentation/git-branch.txt>
> Delete unneeded branch::
> +
> ------------
> $ git clone git://git.kernel.org/.../git.git my.git
> $ cd my.git
> $ git branch -d -r origin/todo origin/html origin/man   <1>
> $ git branch -D test                                    <2>
> ------------
> +
> <1> Delete remote-tracking branches "todo", "html", "man"
> </quote>
> 
> That's *exactly* what I did! And it *doesn't work*! Well, it does delete
> the branches, but they are automagically re-created on the next fetch,
> so "deleting" them this way is useless.

Of course it *does* work. It *deletes* the branches. There is not a single word about stopping fetch getting them!

Obviously given that the example is slightly contrived, it should really be mentioned that it does not affect fetch at all.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>
Jan Hudec· Nov 17, 2007, 19:51 UTC · re: Jan Hudec · lore

[PATCH] Improve description of git-branch -d and -D in man page.

Some users expect that deleting a remote-tracking branch would prevent fetch from creating it again, so be explcit about that it's not the case. Also be a little more explicit about what fully merged means.

Signed-off-by: Jan Hudec <bulb@ucw.cz>
---
On Sat, Nov 17, 2007 at 20:12:56 +0100, Jan Hudec wrote:
Show 23 quoted lines
> On Tue, Nov 13, 2007 at 20:58:20 +0300, osv@javad.com wrote:
> > <quote Documentation/git-branch.txt>
> > Delete unneeded branch::
> > +
> > ------------
> > $ git clone git://git.kernel.org/.../git.git my.git
> > $ cd my.git
> > $ git branch -d -r origin/todo origin/html origin/man   <1>
> > $ git branch -D test                                    <2>
> > ------------
> > +
> > <1> Delete remote-tracking branches "todo", "html", "man"
> > </quote>
> > 
> > That's *exactly* what I did! And it *doesn't work*! Well, it does delete
> > the branches, but they are automagically re-created on the next fetch,
> > so "deleting" them this way is useless.
> 
> Of course it *does* work. It *deletes* the branches. There is not a single
> word about stopping fetch getting them!
> 
> Obviously given that the example is slightly contrived, it should really
> be mentioned that it does not affect fetch at all.
Would this make the description obvious enough?
-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

 Documentation/git-branch.txt |   21 ++++++++++++++-------
 1 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 5ce905d..f87b696 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -45,17 +45,22 @@ to happen.
 
 With a `-d` or `-D` option, `<branchname>` will be deleted.  You may
 specify more than one branch for deletion.  If the branch currently
-has a reflog then the reflog will also be deleted. Use -r together with -d
-to delete remote-tracking branches.
+has a reflog then the reflog will also be deleted.
+
+Use -r together with -d to delete remote-tracking branches. Note, that it
+only makes sense to delete remote-tracking branches if they no longer exist
+in remote repository or if gitlink:git-fetch[1] was configured not to fetch
+them again. See also 'prune' subcommand of gitlink:git-remote[1] for way to
+clean up all obsolete remote-tracking branches.
 
 
 OPTIONS
 -------
 -d::
-	Delete a branch. The branch must be fully merged.
+	Delete a branch. The branch must be fully merged in HEAD.
 
 -D::
-	Delete a branch irrespective of its index status.
+	Delete a branch irrespective of its merged status.
 
 -l::
 	Create the branch's reflog.  This activates recording of
@@ -153,9 +158,11 @@ $ git branch -d -r origin/todo origin/html origin/man   <1>
 $ git branch -D test                                    <2>
 ------------
 +
-<1> Delete remote-tracking branches "todo", "html", "man"
-<2> Delete "test" branch even if the "master" branch does not have all
-commits from test branch.
+<1> Delete remote-tracking branches "todo", "html", "man". Next 'fetch' or
+'pull' will create them again unless you configure them not to. See
+gitlink:git-fetch[1].
+<2> Delete "test" branch even if the "master" branch (or whichever branch is
+currently checked out) does not have all commits from test branch.
 
 
 Notes
-- 
1.5.3.5
Sergei Organov· Nov 19, 2007, 09:49 UTC · re: Jan Hudec · lore

Re: [PATCH] Improve description of git-branch -d and -D in man page.

Jan Hudec <bulb@ucw.cz> writes:
Show 33 quoted lines
> Some users expect that deleting a remote-tracking branch would prevent
> fetch from creating it again, so be explcit about that it's not the case.
> Also be a little more explicit about what fully merged means.
>
> Signed-off-by: Jan Hudec <bulb@ucw.cz>
> ---
>
> On Sat, Nov 17, 2007 at 20:12:56 +0100, Jan Hudec wrote:
>> On Tue, Nov 13, 2007 at 20:58:20 +0300, osv@javad.com wrote:
>> > <quote Documentation/git-branch.txt>
>> > Delete unneeded branch::
>> > +
>> > ------------
>> > $ git clone git://git.kernel.org/.../git.git my.git
>> > $ cd my.git
>> > $ git branch -d -r origin/todo origin/html origin/man   <1>
>> > $ git branch -D test                                    <2>
>> > ------------
>> > +
>> > <1> Delete remote-tracking branches "todo", "html", "man"
>> > </quote>
>> > 
>> > That's *exactly* what I did! And it *doesn't work*! Well, it does delete
>> > the branches, but they are automagically re-created on the next fetch,
>> > so "deleting" them this way is useless.
>> 
>> Of course it *does* work. It *deletes* the branches. There is not a single
>> word about stopping fetch getting them!
>> 
>> Obviously given that the example is slightly contrived, it should really
>> be mentioned that it does not affect fetch at all.
>
> Would this make the description obvious enough?

Yes, I think now it describes the actual behavior much much better, -- thanks.

-- 
Sergei.
Sergei Organov· Nov 13, 2007, 17:47 UTC · re: Steffen Prohaska · lore

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

Steffen Prohaska <prohaska@zib.de> writes: [...]

> 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.

But I don't want to track those real remote branch anymore, so obviously I don't want anything that is "identical" to it, so deleting corresponding remote-tracking branch makes perfect sense, IMHO.

-- 
Sergei.
Andreas Ericsson· Nov 13, 2007, 20:01 UTC · re: Steffen Prohaska · lore

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

Steffen Prohaska wrote:
Show 59 quoted lines
> 
> On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
> 
>> 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:
>> [...]
>>>>> $ 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.

Show 8 quoted lines
> 
>> 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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Andreas Ericsson· Nov 13, 2007, 22:33 UTC · re: Andreas Ericsson · lore

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

Andreas Ericsson wrote:
Show 22 quoted lines
> Steffen Prohaska wrote:
>>
>> 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.
> 

I confess myself corrected. The Documentation/glossary.txt file doesn't mention them at all. It does however describe "tracking branch", and mentions "Pull: " refspecs in the same sentence, indicating that that particular description is a leftover from the pre-1.5 era.

I've got half a patch ready to change all occurrences of anything but "remote-tracking branch" to that self-same description. This is what I've got in Documentation/glossary.txt so far:

[[def_remote_tracking_branch]]remote-tracking branch:
    A "remote-tracking branch" is a branch set up to track the
    state of a branch in a remote repository which the user has named. 
    These branches follow exactly the same rules as the branches which
    reside in the remote repository, except that they are manipulated
    by `git fetch` instead of `git push`. That is, they can only be
    updated if the update would result in a 
    <<def_fastforward,fast forward>>, or if the user supplies the 
    '--force' option. 
    They cannot be checked out or committed to by users, but serve
    solely as local reference-pointers to their corresponding branches
    in the remote repository.
    The most common example of a remote-tracking branch is origin/master.
It's a bit long-winded. Anyone got any improvements?
-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Jakub Narebski· Nov 13, 2007, 22:42 UTC · re: Andreas Ericsson · lore

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

Andreas Ericsson wrote:
Show 15 quoted lines
> This is what I've got in Documentation/glossary.txt so far:
> 
> [[def_remote_tracking_branch]]remote-tracking branch:
>     A "remote-tracking branch" is a branch set up to track the
>     state of a branch in a remote repository which the user has named. 
>     These branches follow exactly the same rules as the branches which
>     reside in the remote repository, except that they are manipulated
>     by `git fetch` instead of `git push`. That is, they can only be
>     updated if the update would result in a 
>     <<def_fastforward,fast forward>>, or if the user supplies the 
>     '--force' option. 
>     They cannot be checked out or committed to by users, but serve
>     solely as local reference-pointers to their corresponding branches
>     in the remote repository.
>     The most common example of a remote-tracking branch is origin/master.
If user supplies '--force' option, ur uses '+<src>:<dst>' refspec
('+<remote branch>:<remote-tracking branch>').
 
> It's a bit long-winded. Anyone got any improvements?
Long winded is good. Well, long is good.
I would add that remote-tracking branches reside in refs/remotes/<remote>.

I would skip the part about `git push`, and just say that they are updated on fetch (`git fetch` or `git pull`).

-- 
Jakub Narebski
Poland
J. Bruce Fields· Nov 13, 2007, 23:05 UTC · re: Andreas Ericsson · lore

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

On Tue, Nov 13, 2007 at 11:33:15PM +0100, Andreas Ericsson wrote:
Show 41 quoted lines
> Andreas Ericsson wrote:
>> Steffen Prohaska wrote:
>>>
>>> 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.
>>
>
> I confess myself corrected. The Documentation/glossary.txt file doesn't
> mention them at all. It does however describe "tracking branch", and
> mentions "Pull: " refspecs in the same sentence, indicating that that
> particular description is a leftover from the pre-1.5 era.
>
> I've got half a patch ready to change all occurrences of anything but
> "remote-tracking branch" to that self-same description. This is what
> I've got in Documentation/glossary.txt so far:
>
> [[def_remote_tracking_branch]]remote-tracking branch:
>    A "remote-tracking branch" is a branch set up to track the
>    state of a branch in a remote repository which the user has named.    
> These branches follow exactly the same rules as the branches which
>    reside in the remote repository, except that they are manipulated
>    by `git fetch` instead of `git push`. That is, they can only be
>    updated if the update would result in a    <<def_fastforward,fast 
> forward>>, or if the user supplies the    '--force' option.
This is a little confusing--by default fetch does force updates.
--b.
Show 17 quoted lines
> They cannot 
> be checked out or committed to by users, but serve
>    solely as local reference-pointers to their corresponding branches
>    in the remote repository.
>    The most common example of a remote-tracking branch is origin/master.
>
>
> It's a bit long-winded. Anyone got any improvements?
>
> -- 
> Andreas Ericsson                   andreas.ericsson@op5.se
> OP5 AB                             www.op5.se
> Tel: +46 8-230225                  Fax: +46 8-230231
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Junio C Hamano· Nov 13, 2007, 23:56 UTC · re: Andreas Ericsson · lore

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

Andreas Ericsson <ae@op5.se> writes:
Show 16 quoted lines
> I've got half a patch ready to change all occurrences of anything but
> "remote-tracking branch" to that self-same description. This is what
> I've got in Documentation/glossary.txt so far:
>
> [[def_remote_tracking_branch]]remote-tracking branch:
>    A "remote-tracking branch" is a branch set up to track the
>    state of a branch in a remote repository which the user has named.
> These branches follow exactly the same rules as the branches which
>    reside in the remote repository, except that they are manipulated
>    by `git fetch` instead of `git push`. That is, they can only be
>    updated if the update would result in a  <<def_fastforward,fast
> forward>>, or if the user supplies the  '--force' option.  They cannot
> be checked out or committed to by users, but serve
>    solely as local reference-pointers to their corresponding branches
>    in the remote repository.
>    The most common example of a remote-tracking branch is origin/master.

Please try to read it as if it were an entry in a glossary. The sentence "... follow exactly the same rules as ..." was "Huh?" to me. "rules? what rules? the set of valid characters in their names?"

When branch 'foo' from remote is tracked with the standard layout (post 1.3.0) it is copied to refs/remotes/origin/foo and people often fork their local branch refs/heads/foo to build on top. The use of the word "corresonding" feels a bit confusing, because you can arguably say refs/heads/foo at remote corresopnds to refs/heads/foo in your repository.

I'd drop "These branches follow ... the '--force' option. " from the above. The rules on how they are updated are irrelevant, before the reader understands what they are for. How about this?

    A "remote tracking branch" remembers which commit a branch
    in the remote repository was pointing at last time you
    checked.  It cannot be checked out or committed because its
    purpose is to serve as a local reference point after you
    built your own changes on top of it in your local branch
    forked from it.  The most common example of a remote
    tracking branch is "origin/master", which tracks the
    "master" branch of the "origin" remote.

BTW, when you have this data-flow (probably typical in a shared repository workflow):

    Remote repository               Your repository
    refs/heads/foo -------(A)------> refs/remotes/origin/foo
         ^                                |
         |                               (B)
         |                                |
         |                                V
         `-------------(C)---------- refs/heads/foo
         (A) "git fetch" with remote.origin.fetch configuration
             set to +refs/heads/*:refs/remotes/origin/* keeps
             your refs/remotes/origin/foo up-to-date with their
             refs/heads/foo
         (B) "git merge origin/foo" while on "foo" branch (there
             are few shorthands like "git pull origin foo" while
             on "foo" branch.  If you say "git branch --track
             foo origin/foo", then running "git pull" without
             parameter while on "foo" branch).
         (C) "git push origin foo".
 * Everybody seems to agree that "refs/remotes/origin/foo" is
   called a "remote tracking branch";
 * Your refs/heads/foo follows and builds on top of 'foo' branch
   at the remote.  Some people errorneously call it "tracking"
   but that is because we do not have a good term for it;
 * There is no good name for "refs/heads/foo at the remote".  We
   always say "the remote branch you follow" (or "track"). 
   
Andreas Ericsson· Nov 14, 2007, 01:02 UTC · re: Junio C Hamano · lore

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

Junio C Hamano wrote:
Show 45 quoted lines
> Andreas Ericsson <ae@op5.se> writes:
> 
>> I've got half a patch ready to change all occurrences of anything but
>> "remote-tracking branch" to that self-same description. This is what
>> I've got in Documentation/glossary.txt so far:
>>
>> [[def_remote_tracking_branch]]remote-tracking branch:
>>    A "remote-tracking branch" is a branch set up to track the
>>    state of a branch in a remote repository which the user has named.
>> These branches follow exactly the same rules as the branches which
>>    reside in the remote repository, except that they are manipulated
>>    by `git fetch` instead of `git push`. That is, they can only be
>>    updated if the update would result in a  <<def_fastforward,fast
>> forward>>, or if the user supplies the  '--force' option.  They cannot
>> be checked out or committed to by users, but serve
>>    solely as local reference-pointers to their corresponding branches
>>    in the remote repository.
>>    The most common example of a remote-tracking branch is origin/master.
> 
> Please try to read it as if it were an entry in a glossary.
> The sentence "... follow exactly the same rules as ..." was
> "Huh?" to me.  "rules?  what rules?  the set of valid characters
> in their names?"
> 
> When branch 'foo' from remote is tracked with the standard layout
> (post 1.3.0) it is copied to refs/remotes/origin/foo and people
> often fork their local branch refs/heads/foo to build on top.
> The use of the word "corresonding" feels a bit confusing,
> because you can arguably say refs/heads/foo at remote
> corresopnds to refs/heads/foo in your repository.
> 
> I'd drop "These branches follow ... the '--force' option.  "
> from the above.  The rules on how they are updated are
> irrelevant, before the reader understands what they are for.
> How about this?
> 
>     A "remote tracking branch" remembers which commit a branch
>     in the remote repository was pointing at last time you
>     checked.  It cannot be checked out or committed because its
>     purpose is to serve as a local reference point after you
>     built your own changes on top of it in your local branch
>     forked from it.  The most common example of a remote
>     tracking branch is "origin/master", which tracks the
>     "master" branch of the "origin" remote.
> 

I'd skip "after you built your own changes ..." and let it go at that. Will amend. Thanks.

Show 28 quoted lines
> BTW, when you have this data-flow (probably typical in a shared
> repository workflow):
> 
>     Remote repository               Your repository
> 
>     refs/heads/foo -------(A)------> refs/remotes/origin/foo
>          ^                                |
>          |                               (B)
>          |                                |
>          |                                V
>          `-------------(C)---------- refs/heads/foo
> 
>          (A) "git fetch" with remote.origin.fetch configuration
>              set to +refs/heads/*:refs/remotes/origin/* keeps
>              your refs/remotes/origin/foo up-to-date with their
>              refs/heads/foo
> 
>          (B) "git merge origin/foo" while on "foo" branch (there
>              are few shorthands like "git pull origin foo" while
>              on "foo" branch.  If you say "git branch --track
>              foo origin/foo", then running "git pull" without
>              parameter while on "foo" branch).
> 
>          (C) "git push origin foo".
> 
>  * Everybody seems to agree that "refs/remotes/origin/foo" is
>    called a "remote tracking branch";
> 

I'd like to insert the significant dash there. remote-tracking vs remote tracking. It solves the one ambiguity with it, and would finally make it clear and consistent almost however it's used.

>  * Your refs/heads/foo follows and builds on top of 'foo' branch
>    at the remote.  Some people errorneously call it "tracking"
>    but that is because we do not have a good term for it;
> 
"private tracking branch"? Nah...
>  * There is no good name for "refs/heads/foo at the remote".  We
>    always say "the remote branch you follow" (or "track"). 
> 

"remote-repo branch" perhaps? The universe doesn't exactly toll its bells in approval at that, but at least it's not ambiguous.

I've seen it written as "remote tracking branch" on irc a few times. It causes 10 minutes of confusion where no-one's sure what anyone else means. With the dash in there, there's no room for ambiguity.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Steffen Prohaska· Nov 14, 2007, 05:48 UTC · re: Andreas Ericsson · lore

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

On Nov 14, 2007, at 2:02 AM, Andreas Ericsson wrote:
Show 25 quoted lines
>> BTW, when you have this data-flow (probably typical in a shared
>> repository workflow):
>>     Remote repository               Your repository
>>     refs/heads/foo -------(A)------> refs/remotes/origin/foo
>>          ^                                |
>>          |                               (B)
>>          |                                |
>>          |                                V
>>          `-------------(C)---------- refs/heads/foo
>>          (A) "git fetch" with remote.origin.fetch configuration
>>              set to +refs/heads/*:refs/remotes/origin/* keeps
>>              your refs/remotes/origin/foo up-to-date with their
>>              refs/heads/foo
>>          (B) "git merge origin/foo" while on "foo" branch (there
>>              are few shorthands like "git pull origin foo" while
>>              on "foo" branch.  If you say "git branch --track
>>              foo origin/foo", then running "git pull" without
>>              parameter while on "foo" branch).
>>          (C) "git push origin foo".
>>  * Everybody seems to agree that "refs/remotes/origin/foo" is
>>    called a "remote tracking branch";
>
> I'd like to insert the significant dash there. remote-tracking vs
> remote tracking. It solves the one ambiguity with it, and would
> finally make it clear and consistent almost however it's used.
I recently tried to explain it in the following way:

"refs/remotes/origin/foo" mirrors the original branch (from the remote repository) in your local repository. Because it is an identical copy of the branch in the remote repository it is also called a "remote-tracking branch" or sometimes just a "remote branch", although it is stored locally in your repository.

Show 5 quoted lines
>>  * Your refs/heads/foo follows and builds on top of 'foo' branch
>>    at the remote.  Some people errorneously call it "tracking"
>>    but that is because we do not have a good term for it;
>
> "private tracking branch"? Nah...

"refs/heads/foo" is your local branch that you work on. Typically, it's simply called branch foo. However you can say "my local branch" foo to emphasis that it's your branch. This branch is set up in a way to automatically merge changes from the remote branch it was created from. It is sometimes said to "track" a remote branch, however it must not be confused with a "remote-tracking branch". The terminology used in the documentation is sometimes confusing. A clear statement is: "My local branch foo is configured to automatically merge the remote (tracking) branch origin/foo, with origin configured to point to git://server/path/to/repo.git."

Show 5 quoted lines
>>  * There is no good name for "refs/heads/foo at the remote".  We
>>    always say "the remote branch you follow" (or "track").
>
> "remote-repo branch" perhaps? The universe doesn't exactly toll its
> bells in approval at that, but at least it's not ambiguous.

Typically, the original branch in the remote repository and its local remote-tracking branch point to the same commit; or you can easy update the local copy with fetch. So, often they are not distinguished. But you can say "branch foo from the remote repository git://server/path/to/repo.git" is mirrored locally as "remote-tracking branch origin/foo" if you need to be precise.

If you say "I merged origin/foo" it really does not matter if you mean the branch in the remote repository or its local remote-tracking branch. In both cases the reader needs context to understand what you exactly mean. If you want to be precise here, you can say "I merged commit <sha1>".

A technical note: The '--track' option sets up the local branch to track the original branch in the remote repository. The setup is not referring to a local remote-tracking branch at all. config.<branch>.merge contains the branch as it is named in the remote repository. git is automatically merging from the branch in the remote repository. The remote-tracking branch would not be needed to do this. So I think it's not a problem that "remote branch foo" sometimes means the branch in the remote repository and sometimes means its local remote-tracking branch. What you really mean in both cases is the original branch in the remote repository. If you want to explicitly point to a specific commit you need to name it by other means (sha1) anyway.

> I've seen it written as "remote tracking branch" on irc a few times.
> It causes 10 minutes of confusion where no-one's sure what anyone
> else means. With the dash in there, there's no room for ambiguity.
I believe dash is a good idea.
	Steffen
Sergei Organov· Nov 13, 2007, 17:40 UTC · re: Jakub Narebski · lore

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

Jakub Narebski <jnareb@gmail.com> writes:
Show 44 quoted lines
> 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:
> [...]
>>>> $ 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.

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?

> 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!
-- 
Sergei.
Jakub Narebski· Nov 13, 2007, 19:17 UTC · re: Sergei Organov · lore

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

Sergei Organov wrote:
Show 11 quoted lines
> 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:
[...] 
Show 23 quoted lines
>>>       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.
Show 5 quoted lines
>> 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

← back to recent threads