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

Junio C Hamano schrieb:

* 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.)

Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them.  I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir.  This may
need to happen anyway as mingw fallouts, though ;-).

Heh. 'git help -a' currently shows nothing. But it has nothing to do with 
hardlinks. It's because the test for the executable bit fails :-(

BTW, we do use hardlinks on Windows; even the MsysGit installer creates them 
(as long as the filesystem is NTFS). So, the fallout you are 
expecting/hoping for will not be in the first round of MinGW port patches. ;)

-- Hannes