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

[Johannes Sixt <j.sixt@viscovery.net>]

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