Re: Globbing for ignored branches?
- From
- Markus Trippelsdorf <markus@trippelsdorf.de>
- Date
- Jan 25, 2014, 14:15 UTC
- Message-ID
- <20140125141542.GA402@x4>
- In-Reply-To
- <20140125013433.GA22336@sigill.intra.peff.net>
On 2014.01.24 at 20:34 -0500, Jeff King wrote:
Show 19 quoted lines
> On Fri, Jan 24, 2014 at 01:08:42PM -0800, Junio C Hamano wrote: > > > Not really. You do not have to view it as "'not refs/heads/foo' is > > affecting the previous '+refs/heads/*:refs/remotes/origin/*'". > > > > You can think of two refspecs "refs/heads/foo refs/heads/bar" are > > both affecting the "end result"; so far we only had a single way for > > multiple refspecs to affect the end result and that was a "union". > > Introducing "subtract" as another mode of combining is not too bad, > > I would think, at the conceptual level. > > > I tend to agree that "refs/heads/foo:" is being too cute and may be > > confusing, at least if it will be the only way to express this in > > the end-user-facing UI. Even some people were confused enough on a > > very sensible "push nothing to ref means deletion" to make us add > > another explicit way, "push --delete", to ask for the same thing. > > Agreed. I went with "^refs/heads/master" in the patch below, but I am > open to other suggestions.
Many thanks for the patch. It seems to work as advertised, but only if the negative refspec appears on a separate line. For example:
[remote "origin"]
url = git://gcc.gnu.org/git/gcc.git
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = ^refs/remotes/hjlworks fine, but:
[remote "origin"]
url = git://gcc.gnu.org/git/gcc.git
fetch = +refs/heads/*:refs/remotes/origin/* ^refs/remotes/hjl doesn't. (I think this happens because bad_ref_char in refs.c checks for '^'.)
-- Markus