# [PATCH] Allow fetching references from any namespace 6 messages from 2007-05-11 to 2007-05-13. Participants: Alex Riesen, Junio C Hamano, Marco Costalba, Jan Hudec. Thread: https://gitlist.dev/t/8087 ## Alex Riesen, 2007-05-11 20:35 Subject: [PATCH] Allow fetching references from any namespace Message-ID: <20070511203522.GA2741@steel.home> URL: https://gitlist.dev/e/20070511203522.GA2741%40steel.home ``` not only from the three defined: heads, tags and remotes. Noticed when I tried to fetch the references created by git-p4-import.bat: they are placed into separate namespace (refs/p4import/, to avoid showing them in git-branch output). As canon_refs_list_for_fetch always prepended refs/heads/ it was impossible, and annoying: it worked before. Normally, the p4import references are useless anywhere but in the directory managed by perforce, but in this special case the cloned directory was supposed to be a backup, including the p4import branch: it keeps information about where the imported perforce state came from. Signed-off-by: Alex Riesen --- git-parse-remote.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/git-parse-remote.sh b/git-parse-remote.sh index 437b0c3..0506b12 100755 --- a/git-parse-remote.sh +++ b/git-parse-remote.sh @@ -143,13 +143,13 @@ canon_refs_list_for_fetch () { fi case "$remote" in '' | HEAD ) remote=HEAD ;; - refs/heads/* | refs/tags/* | refs/remotes/*) ;; + refs/*) ;; heads/* | tags/* | remotes/* ) remote="refs/$remote" ;; *) remote="refs/heads/$remote" ;; esac case "$local" in '') local= ;; - refs/heads/* | refs/tags/* | refs/remotes/*) ;; + refs/*) ;; heads/* | tags/* | remotes/* ) local="refs/$local" ;; *) local="refs/heads/$local" ;; esac -- 1.5.2.rc3.17.ge713 ``` ## Junio C Hamano, 2007-05-11 20:54 Subject: Re: [PATCH] Allow fetching references from any namespace Message-ID: <7vlkfv9j3c.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vlkfv9j3c.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20070511203522.GA2741@steel.home> ``` Alex Riesen writes: > not only from the three defined: heads, tags and remotes. > > Noticed when I tried to fetch the references created by git-p4-import.bat: > they are placed into separate namespace (refs/p4import/, to avoid showing > them in git-branch output). As canon_refs_list_for_fetch always prepended > refs/heads/ it was impossible, and annoying: it worked before. Normally, > the p4import references are useless anywhere but in the directory managed > by perforce, but in this special case the cloned directory was supposed > to be a backup, including the p4import branch: it keeps information about > where the imported perforce state came from. Have no objection to the patch itself, but mind pointing out where we broke it (I suspect it is around 1.5.0)? ``` ## Alex Riesen, 2007-05-12 07:40 Subject: Re: [PATCH] Allow fetching references from any namespace Message-ID: <20070512074049.GA2410@steel.home> URL: https://gitlist.dev/e/20070512074049.GA2410%40steel.home In-Reply-To: <7vlkfv9j3c.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano, Fri, May 11, 2007 22:54:47 +0200: > Alex Riesen writes: > > > not only from the three defined: heads, tags and remotes. > > > > Noticed when I tried to fetch the references created by git-p4-import.bat: > > they are placed into separate namespace (refs/p4import/, to avoid showing > > them in git-branch output). As canon_refs_list_for_fetch always prepended > > refs/heads/ it was impossible, and annoying: it worked before. Normally, > > the p4import references are useless anywhere but in the directory managed > > by perforce, but in this special case the cloned directory was supposed > > to be a backup, including the p4import branch: it keeps information about > > where the imported perforce state came from. > > Have no objection to the patch itself, but mind pointing out > where we broke it (I suspect it is around 1.5.0)? > Maybe even much earlier. According to git log -p --decorate -- git-fetch-script git-parse-remote-script commit ac4b0cff00b7629657e61a1d6e1f1a1250d03198 Author: Junio C Hamano Date: Sat Aug 20 02:52:24 2005 -0700 [PATCH] Start adding the $GIT_DIR/remotes/ support. +canon_refs_list_for_fetch () { + for ref + do + expr "$ref" : '.*:' >/dev/null || ref="${ref}:" + remote=$(expr "$ref" : '\([^:]*\):') + local=$(expr "$ref" : '[^:]*:\(.*\)') + case "$remote" in + '') remote=HEAD ;; + *) remote="refs/heads/$remote" ;; + esac + case "$local" in + '') local= ;; + *) local="refs/heads/$local" ;; + esac + echo "${remote}:${local}" + done +} it was this way since at least Aug 2005. ``` ## Junio C Hamano, 2007-05-12 07:55 Subject: Re: [PATCH] Allow fetching references from any namespace Message-ID: <7vveey4gt0.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vveey4gt0.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20070512074049.GA2410@steel.home> ``` Alex Riesen writes: > Junio C Hamano, Fri, May 11, 2007 22:54:47 +0200: >> Alex Riesen writes: >> >> > not only from the three defined: heads, tags and remotes. >> > >> > Noticed when I tried to fetch the references created by git-p4-import.bat: >> > they are placed into separate namespace (refs/p4import/, to avoid showing >> > them in git-branch output). As canon_refs_list_for_fetch always prepended >> > refs/heads/ it was impossible, and annoying: it worked before. Normally, >> > the p4import references are useless anywhere but in the directory managed >> > by perforce, but in this special case the cloned directory was supposed >> > to be a backup, including the p4import branch: it keeps information about >> > where the imported perforce state came from. >> >> Have no objection to the patch itself, but mind pointing out >> where we broke it (I suspect it is around 1.5.0)? >> > > Maybe even much earlier. According to > > git log -p --decorate -- git-fetch-script git-parse-remote-script > > commit ac4b0cff00b7629657e61a1d6e1f1a1250d03198 > Author: Junio C Hamano > Date: Sat Aug 20 02:52:24 2005 -0700 > > [PATCH] Start adding the $GIT_DIR/remotes/ support. Sounds like it is not even a regression but just was not supposed to work from the beginning. Not that I think lifting that restriction is a bad idea, though. ``` ## Marco Costalba, 2007-05-13 03:48 Subject: Re: [PATCH] Allow fetching references from any namespace Message-ID: URL: https://gitlist.dev/e/e5bfff550705122048s6772db3as63f6fb23fe7e1bd7%40mail.gmail.com In-Reply-To: <7vveey4gt0.fsf@assigned-by-dhcp.cox.net> ``` On 5/12/07, Junio C Hamano wrote: > > Sounds like it is not even a regression but just was not > supposed to work from the beginning. > > Not that I think lifting that restriction is a bad idea, > though. > > - > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please consider that StGIT put patch names under refs/patches and probably we don't want to see them. I'm very sorry but I cannot test my-self because I'm leaving now. I have just seen the patch applied in git tree and this thing come to my mind. Marco ``` ## Jan Hudec, 2007-05-13 07:24 Subject: Re: [PATCH] Allow fetching references from any namespace Message-ID: <20070513072409.GD8983@efreet.light.src> URL: https://gitlist.dev/e/20070513072409.GD8983%40efreet.light.src In-Reply-To: ``` On Sun, May 13, 2007 at 05:48:00 +0200, Marco Costalba wrote: > On 5/12/07, Junio C Hamano wrote: > > > >Sounds like it is not even a regression but just was not > >supposed to work from the beginning. > > > >Not that I think lifting that restriction is a bad idea, > >though. > > > >- > >To unsubscribe from this list: send the line "unsubscribe git" in > >the body of a message to majordomo@vger.kernel.org > >More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > Please consider that StGIT put patch names under refs/patches and > probably we don't want to see them. If you don't add them to the push configuration, you won't see them. > I'm very sorry but I cannot test my-self because I'm leaving now. I > have just seen the patch applied in git tree and this thing come to my > mind. It does not make them pushed. It just allows pushing them--which is good thing sometimes (eg. if you use push to backup the repo). -- Jan 'Bulb' Hudec ```