Re: Globbing for ignored branches?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> 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.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]