Deletion of remote branches

Hi,

I came across an issue with deleting remote branches: When deleting a branch using "git branch ­r ­d <branch>" the branch is deleted and no longer shown by "git branch ­r".

"git ls-remote --heads" on the other hand still lists the ref for the last branch commit.

If I delete the branch using "git push origin :<branch>" the branch is removed completely (i.e. git ls-remote no longer returns a ref).

Is this a bug or is this behavior intentional? (I am currently using git 1.7.12).

Cheers, Jens

Jens Hausherr <Jens.Hausherr@xing.com> writes:

All of the above are expected and working as designed. Remote tracking branches are local _copies_ of what you have over there at the remote repository. The latter is the authoritative version, and you asked "ls-remote" to go over the network to view them.

If you are trying to remove the branches you show to others and yourself who are observing that remote repository from your local workstation, you can first "git push origin :<branch>" to remove it in the remote repository. You can run your next fetch with "--prune" to get rid of remotes/origin/<branch>, I think.

From: "Junio C Hamano" <gitster@pobox.com>

Is there a definitive naming convention for the two types of 'remote branch'?

IIRC (somewhere) the 'tracking' term was to be deprecated, though it is still in common use. It is usually only the context that clarifies if it is the local or the distant copy/repo.

Distinct names make for less confusion.

Philip 

"Philip Oakley" <philipoakley@iee.org> writes:

That is somewhat different from what I recall:

 - "refs/remotes/$there/$that" is a copy of $that branch at the
   remote $there; we call that a "remote tracking branch".

   When people say "remote branch", they often mean $that branch at
   the remote $there, not your local copy of it.

   When you say "remote tracking branch", you are talking about
   something you locally have to track the corresponding "remote
   branch".  This use is not deprecated at all.  That is the only
   sane way to clarify which one of the two you are talking about.

 - If your branch "foo" always integrates with branch "bar" at the
   remote "xyzzy", you would often run

	git pull xyzzy bar
        git pull --rebase xyzzy bar

   after running "git chekcout foo".  You may even have this in your
   per-repository configuration:

	[branch "foo"]
		remote = xyzzy
                merge = refs/heads/bar

   In such a situation, some people (used to) say that "foo tracks
   bar from xyzzy".  While such a colloquial use is perfectly fine
   when it is clear that "foo" being discussed is your local branch,
   the verb "track" in that sentence is used to mean an entirely
   different kind of relationship between your "remotes/xyzzy/bar"
   and the branch "bar" at remote "xyzzy", where the former is the
   "remote tracking branch" for the latter, leading to confusion.
   This use of 'track' is what is discouraged these days.

I think we call the latter @{upstream} of "foo" these days.

Ok, thanks for clarifying this.

"Philip Oakley" <philipoakley@iee.org> writes: