Sergei Organov wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: >> Sergei Organov <osv@xxxxxxxxx> wrote: >>> Jakub Narebski <jnareb@xxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
