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

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

[Sergei Organov]

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.

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

[Jakub Narebski]

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

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

[Sergei Organov]

Jakub Narebski <jnareb@gmail.com> writes:

> [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/*

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

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

[Johannes Schindelin]

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_!

Ciao,
Dscho

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

[Sergei Organov]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

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

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

[Johannes Schindelin]

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

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

[Sergei Organov]

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

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

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

On Tue, Nov 13, 2007 at 21:44:11 +0300, Sergei Organov wrote:
> 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.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jakub Narebski]

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.

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

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

[Steffen Prohaska]

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?


> 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

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

[Jakub Narebski]

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.

-- 
Jakub Narebski
Poland

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

[osv]

Jakub Narebski <jnareb@gmail.com> writes:
> 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.

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

[Lars Hjemli]

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.

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

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

[Sergei Organov]

"Lars Hjemli" <hjemli@gmail.com> writes:

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

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

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

[Steffen Prohaska]

On Nov 13, 2007, at 6:58 PM, <osv@javad.com> <osv@javad.com> wrote:

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

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

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

On Tue, Nov 13, 2007 at 20:58:20 +0300, osv@javad.com wrote:
> 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>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jan Hudec]

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?

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

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

[Sergei Organov]

Jan Hudec <bulb@ucw.cz> writes:
> 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.

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

[Sergei Organov]

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.

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

[Andreas Ericsson]

Steffen Prohaska wrote:
> 
> 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.

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

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

[Andreas Ericsson]

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

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

[Jakub Narebski]

Andreas Ericsson wrote:

> 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

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

[J. Bruce Fields]

On Tue, Nov 13, 2007 at 11:33:15PM +0100, Andreas Ericsson wrote:
> 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.

> 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

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

[Junio C Hamano]

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.

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

   

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

[Andreas Ericsson]

Junio C Hamano wrote:
> 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.

> 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

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

[Steffen Prohaska]

On Nov 14, 2007, at 2:02 AM, Andreas Ericsson wrote:

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


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


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

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

[Sergei Organov]

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:
> [...]
>>>> $ 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.

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

[Jakub Narebski]

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