From: Junio C Hamano Date: Fri, 24 Jan 2014 21:08:42 GMT Subject: Re: Globbing for ignored branches? Message-ID: In-Reply-To: <20140124204825.GA17167@sigill.intra.peff.net> Jeff King writes: > I had imagined a "not" token at the front of the refspec, like: > > git fetch origin +refs/heads/*:refs/remotes/origin/* ^refs/heads/foo > > In this case, a colon in the refspec would be an error. An alternative > would be: > > git fetch origin +refs/heads/*:refs/remotes/origin/* refs/heads/foo: > > I.e., to say "put foo to nowhere". But generally refspecs do not affect > each other. 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. > ... Making the "null destination" work > differently might be confusing. 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.