Re: Regression: Multi-head syntax

From: Junio C Hamano <junkio@cox.net>
Date: Oct 13, 2005, 22:36 UTC
Message-ID: <7v4q7l11tr.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0510132225120.1028@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 20 quoted lines

> with 221e743c.. [git-fetch --tags: deal with tags with spaces in them.] my 
> usual git-fetch no longer works. My .git/remotes/junio used to look like 
> this:
>
> -- snip --
> URL: rsync://rsync.kernel.org/pub/scm/git/git.git
> Pull: master:junio todo:todo +pu:pu
> -- snap --
>
> but this makes a new head "junio todo:todo +pu:pu". Now I have to write 
> the remote like this to work correctly:
>
> -- snip --
> URL: rsync://rsync.kernel.org/pub/scm/git/git.git
> Pull: master:junio
> Pull: todo:todo
> Pull: +pu:pu
> -- snap --
>
> Is this intended?

Unintended regression whose solution is not quite decided. My current thinking is to disallow refnames that:

     * have a path component that begins with a ".", or
     * have two consecutive dots "..", or
     * have ASCII control character, "~", "^", ":" or SP, anywhere, or
     * end with a "/".

and there are series of commits to enforce the above (except two dots) in the proposed updates branch.

The first one does not have much technical reason for it, but is just easier on eye, and we do not have to worry about /./ or /../ if we have that rule. The second one is so that "ref1..ref2" notation that means "^ref1 ref2" in some tools would be unambiguous.

SP and TAB are because of the shell splicing tokens at IFS, LF is because of remote/ file format, and forbidding the rest of the control characters are "not strictly necessariy but why not while we are at it?" "~" and "^" are "follow-the-parent" postfix operators, and ":" separates a src:dst pair in a refspec.

There is a thread on this:

	http://marc.theaimsgroup.com/?l=git&m=112901070817153&w=2

It appears to me that the list does not have many objections to the above restriction, so that change can goes in now after double-dot fixes, and perhaps after fixing cvs/arch import to munge the tag/branch names appropriately, we can revert the IFS="$LF" change in git-fetch that is giving you this trouble,

This is slightly offtopic, but could you switch to http transport? Rsync has been deprecated for quite some time.