Re: Regression: Multi-head syntax

From: Junio C Hamano <junkio@cox.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: Regression: Multi-head syntax
Date: Thu, 13 Oct 2005 15:36:48 -0700	[thread overview]
Message-ID: <7v4q7l11tr.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0510132225120.1028@wbgn013.biozentrum.uni-wuerzburg.de> (Johannes Schindelin's message of "Thu, 13 Oct 2005 22:28:50 +0200 (CEST)")

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

> 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.