From: Johannes Sixt Date: Tue, 04 Dec 2007 09:40:20 GMT Subject: Re: What's cooking in git.git (topics) Message-ID: <47552084.3070601@viscovery.net> In-Reply-To: <7vy7ca6ea9.fsf@gitster.siamese.dyndns.org> 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