Re: What's cooking in git.git (topics)

On Dec 4, 2007, at 10:40 AM, Johannes Sixt wrote:

Junio C Hamano schrieb:

quoted

* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
 + refactor fetch's ref matching to use refname_match()
 + push: use same rules as git-rev-parse to resolve refspecs
 + add refname_match()
 + push: support pushing HEAD to real branch name
The last one changes the semantics to somewhat less safe:
    * We did not allow fetching outside refs/ (except HEAD), but  
now we
      allow any random string.
    * We used to restrict fetching names that do not begin with  
refs/ to
      heads, tags and remotes, but now the code grabs anything  
underneath
      refs/.
which could invite mistakes by letting typos slip through, but I  
won't
be a good judge, as I probably "fetch" much less often than other  
people
do and these may be non issues in the real-world usecases.  It  
could be
that I am worried too much needlessly.  If anybody who is following
'next' has been bitten by the change, please speak up.  Otherwise  
this
will go in soon.

Forks on repo.or.cz use the namespace refs/forkee that lists  
everything that the forkee has below refs/. So this change might  
indeed be annoying. (But I'm not using next, so I can't tell, yet.)

But only if you accidentally wrote

    git fetch forkee/heads/something

instead of

    git fetch heads/something

which I don't think is a very likely typo.

With the last change, fetch still requires a match of the full
refspec created by prefixing a short refspec with "refs/".
Different from the old behaviour, it does no longer verify
that the short refspec from the command line starts with
heads, tags, or remotes.  However, it does _not_ recurse
into "sub-directories" to find a matching ref.  It won't
recurse into forkee, unless you explicitly tell fetch to look
in forkee.  With the old implementation you'd have to say
"refs/forkee/heads/something", while the new implementation
would also accept "forkee/heads/something".

	Steffen