On 2014.01.25 at 15:15 +0100, Markus Trippelsdorf wrote:
> On 2014.01.24 at 20:34 -0500, Jeff King wrote:
> > 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:
I've posted a wrong negative refspec. Sorry. Correction below.
> [remote "origin"]
> url = git://gcc.gnu.org/git/gcc.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> fetch = ^refs/remotes/hjl
fetch = ^refs/remotes/origin/hjl
> works fine, but:
>
> [remote "origin"]
> url = git://gcc.gnu.org/git/gcc.git
> fetch = +refs/heads/*:refs/remotes/origin/* ^refs/remotes/hjl
fetch = +refs/heads/*:refs/remotes/origin/* ^refs/remotes/origin/hjl
> doesn't. (I think this happens because bad_ref_char in refs.c checks for '^'.)
--
Markus
--
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