Jacob Keller <jacob.e.keller@xxxxxxxxx> writes: > From: Jacob Keller <jacob.keller@xxxxxxxxx> > > Both fetch and push support pattern refspecs which allow fetching or > pushing references that match a specific pattern. Because these patterns > are globs, they have somewhat limited ability to express more complex > situations. > > For example, suppose you wish to fetch all branches from a remote except > for a specific one. To allow this, you must setup a set of refspecs > which match only the branches you want. Because refspecs are either > explicit name matches, or simple globs, many patterns cannot be > expressed. > > Add support for a new type of refspec, referred to as "negative" > refspecs. These are prefixed with a '^' and mean "exclude any ref > matching this refspec". They can only have one "side" which always > refers to the source. During a fetch, this refers to the name of the ref > on the remote. During a push, this refers to the name of the ref on the > local side. > > With negative refspecs, users can express more complex patterns. For > example: > > git fetch origin refs/heads/*:refs/remotes/origin/* ^refs/heads/dontwant > > will fetch all branches on origin into remotes/origin, but will exclude > fetching the branch named dontwant. > > Refspecs today are commutative, meaning that order doesn't expressly > matter. Rather than forcing an implied order, negative refspecs will > always be applied last. That is, in order to match, a ref must match at > least one positive refspec, and match none of the negative refspecs. > This is similar to how negative pathspecs work. > > Signed-off-by: Jacob Keller <jacob.keller@xxxxxxxxx> > --- > > I realize this probably needs to be broken down into multiple patches, but I > haven't quite figured out the best way to do that. I'd like to avoid the > case where a commit has support for parsing negative refspecs but code paths > which use refspecs aren't handling them correctly. Thoughts? > > Splitting would also allow additional space for explanations of some of the > trickier logic. > > I am also definitely looking for more test ideas, to help make sure we > cover a good variety of the flows. Anybody wants to help this move forward? I plan to send a review with the patch in the current form, without waiting for any splitting, later towards the weekend, though.
