{"thread":{"id":"2096","subject":"Regression: Multi-head syntax","startedAt":"2005-10-13T20:28:50Z","lastAt":"2005-10-13T22:36:48Z","messageCount":2,"participants":["Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10080","messageId":"Pine.LNX.4.63.0510132225120.1028@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2096","inReplyTo":null,"subject":"Regression: Multi-head syntax","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-10-13T20:28:50Z","receivedAt":"2005-10-13T20:28:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nwith 221e743c.. [git-fetch --tags: deal with tags with spaces in them.] my \nusual git-fetch no longer works. My .git/remotes/junio used to look like \nthis:\n\n-- snip --\nURL: rsync://rsync.kernel.org/pub/scm/git/git.git\nPull: master:junio todo:todo +pu:pu\n-- snap --\n\nbut this makes a new head \"junio todo:todo +pu:pu\". Now I have to write \nthe remote like this to work correctly:\n\n-- snip --\nURL: rsync://rsync.kernel.org/pub/scm/git/git.git\nPull: master:junio\nPull: todo:todo\nPull: +pu:pu\n-- snap --\n\nIs this intended?\n\nCiao,\nDscho\n"},{"id":"10085","messageId":"7v4q7l11tr.fsf@assigned-by-dhcp.cox.net","threadId":"2096","inReplyTo":"Pine.LNX.4.63.0510132225120.1028@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Regression: Multi-head syntax","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-13T22:36:48Z","receivedAt":"2005-10-13T22:36:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> with 221e743c.. [git-fetch --tags: deal with tags with spaces in them.] my \n> usual git-fetch no longer works. My .git/remotes/junio used to look like \n> this:\n>\n> -- snip --\n> URL: rsync://rsync.kernel.org/pub/scm/git/git.git\n> Pull: master:junio todo:todo +pu:pu\n> -- snap --\n>\n> but this makes a new head \"junio todo:todo +pu:pu\". Now I have to write \n> the remote like this to work correctly:\n>\n> -- snip --\n> URL: rsync://rsync.kernel.org/pub/scm/git/git.git\n> Pull: master:junio\n> Pull: todo:todo\n> Pull: +pu:pu\n> -- snap --\n>\n> Is this intended?\n\nUnintended regression whose solution is not quite decided.  My\ncurrent thinking is to disallow refnames that:\n\n     * have a path component that begins with a \".\", or\n     * have two consecutive dots \"..\", or\n     * have ASCII control character, \"~\", \"^\", \":\" or SP, anywhere, or\n     * end with a \"/\".\n\nand there are series of commits to enforce the above (except two\ndots) in the proposed updates branch.\n\nThe first one does not have much technical reason for it, but is\njust easier on eye, and we do not have to worry about /./ or\n/../ if we have that rule.  The second one is so that\n\"ref1..ref2\" notation that means \"^ref1 ref2\" in some tools\nwould be unambiguous.\n\nSP and TAB are because of the shell splicing tokens at IFS, LF\nis because of remote/ file format, and forbidding the rest of\nthe control characters are \"not strictly necessariy but why not\nwhile we are at it?\"  \"~\" and \"^\" are \"follow-the-parent\"\npostfix operators, and \":\" separates a src:dst pair in a\nrefspec.\n\nThere is a thread on this:\n\n\thttp://marc.theaimsgroup.com/?l=git&m=112901070817153&w=2\n\nIt appears to me that the list does not have many objections to\nthe above restriction, so that change can goes in now after\ndouble-dot fixes, and perhaps after fixing cvs/arch import to\nmunge the tag/branch names appropriately, we can revert the\nIFS=\"$LF\" change in git-fetch that is giving you this trouble,\n\nThis is slightly offtopic, but could you switch to http\ntransport?  Rsync has been deprecated for quite some time.\n"}]}