On Fri, 6 Mar 2009, Jay Soffian wrote: > On Thu, Mar 5, 2009 at 11:56 PM, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > > This series only supports the narrowest case of having the * in the middle > > of a side of a refspec: having it as a full path component on each side. > > > > Patches 1-3 centralize all of the parsing and matching rules to a pair of > > functions; patch 4 makes the stored representation more convenient (and > > serves as a distinguished bisection outcome for anything I missed that was > > relying on the contents of struct refspec for patterns); and patch 5 > > extends the matching implementation and loosens the ref format > > requirements to allow the * to be in the middle. > > > > An easy followup would relax the restrictions further without requiring > > any particularly tricky further changes. > > This series and js/remote-improvements (e5dcbfd) in pu may not get > along completely. "git remote show" tries to show how the refspecs > expand out. And actually, that should be fine since builtin-remote now > uses the same code as fetch/push to expand the refs. > > However, "git remote show -n" (-n means don't query the remote) makes > use of a new function, get_push_ref_states_noquery(), which more or > less tries to reverse the parsed refspec back into the original > string. That function relies on the current (before your patch) > refspec semantics and assumes if refspec.pattern is set, then the '*' > is at the end. So it will need tweaking. Actually, you should be able to just drop your "buf" and use spec->src and spec->dst, since it just stores the original strings. So that should be easy enough, although it might be good to go through a remote.c function just in case it becomes more complicated later. On the other hand, get_head_names() should probably get a patch like my 1/5 to have it use the remote.c parser, or should use a constant "head mirror" refspec like that tag_refspec already in remote.c Do you have tests for "git remote show -n"? Merging my series (on top of origin/master) and e5dcbfd and adding a final '*' to the string in get_head_names() made everything pass for me, without doing anything about the extra *s, but the output is clearly not quite right. I'm not seeing anything that makes assumptions about the matching semantics of pattern refspecs, just stuff about how the stored form relates to the config-file form. -Daniel *This .sig left intentionally blank* -- 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
