From: Sergei Organov <hidden> Date: 2016-06-15 22:43:50
Jakub Narebski [off-list ref] writes:
[Cc: Sergei Organov [off-list ref], git@vger.kernel.org]
Please CC git mailing list, git@vger.kernel.org
Sergei Organov wrote:
quoted
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:
quoted
$ 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.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:50
Hi,
On Tue, 13 Nov 2007, Sergei Organov wrote:
Jakub Narebski [off-list ref] writes:
quoted
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:43:50
Sergei Organov [off-list ref] wrote:
Jakub Narebski [off-list ref] writes:
quoted
Sergei Organov wrote:
quoted
quoted
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:
[...]
quoted
quoted
$ 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
On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
Sergei Organov [off-list ref] wrote:
quoted
Jakub Narebski [off-list ref] writes:
quoted
Sergei Organov wrote:
quoted
quoted
quoted
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:
[...]
quoted
quoted
quoted
$ 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/*
[...]
quoted
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:43:50
Steffen Prohaska wrote:
On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
quoted
Sergei Organov [off-list ref] wrote:
quoted
quoted
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.
quoted
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
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:50
Steffen Prohaska wrote:
On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
quoted
Sergei Organov [off-list ref] wrote:
quoted
Jakub Narebski [off-list ref] writes:
quoted
Sergei Organov wrote:
quoted
quoted
quoted
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:
[...]
quoted
quoted
quoted
$ 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/*
[...]
quoted
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.
quoted
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
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:50
Andreas Ericsson wrote:
Steffen Prohaska wrote:
quoted
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:43:50
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
From: J. Bruce Fields <hidden> Date: 2016-06-15 22:43:50
On Tue, Nov 13, 2007 at 11:33:15PM +0100, Andreas Ericsson wrote:
Andreas Ericsson wrote:
quoted
Steffen Prohaska wrote:
quoted
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