git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Regression: Multi-head syntax
@ 2005-10-13 20:28 Johannes Schindelin
  2005-10-13 22:36 ` Junio C Hamano
  0 siblings, 1 reply; 2+ messages in thread
From: Johannes Schindelin @ 2005-10-13 20:28 UTC (permalink / raw)
  To: git

Hi,

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?

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Regression: Multi-head syntax
  2005-10-13 20:28 Regression: Multi-head syntax Johannes Schindelin
@ 2005-10-13 22:36 ` Junio C Hamano
  0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2005-10-13 22:36 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-10-13 22:36 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-10-13 20:28 Regression: Multi-head syntax Johannes Schindelin
2005-10-13 22:36 ` Junio C Hamano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).