Re: [PATCH] disallow refs containing successive slashes

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Oct 12, 2009, 00:31 UTC
Message-ID: <20091012003115.GA5782@progeny.tock>
In-Reply-To: <7vbpkdwyo2.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 6 quoted lines

> When the users make typoes (e.g. /foo//bar) you can accept the only sane
> correction (e.g. foo/bar) instead of rejecting, since the only thing the
> user can do after getting such a rejection is to correct it to that
> corrected name (e.g. foo/bar) himself and re-issue the command anyway.
> You can push the "hassle" down to the user, or you can fix the tool to
> remove the hassle from the user.

Yes, making check-ref-format stricter without changing its users to massage their input would be a regression.

The problem Jens described is a git-gui bug. In lib/branch_delete.tcl, line 57, the list of deletable branches is populated as follows:

	foreach h [load_all_heads] {
		if {$h ne $current_branch} {
			$w_heads insert end $h
		}
	}

Since slashes coalesce, a user-supplied new branch name is not canonical and checking "$h eq $current_branch" does not actually check if they are the same branch. git-gui should be using the branch name as output by "git check-ref-format --branch" after the branch is created.

But what about other scripts that assume each branch has only one possible name? Maybe they could be forced to fix up the name early on by making check-ref-format reject names with "//" in them and providing a "git check-ref-format --print" to help.

Upside: scripts would complain loudly instead of failing subtly on input
with extra slashes if they forget to use "git check-ref-format --print"
when appropriate.  Downside: users, including the 22 callers of
check_ref_format() in git, would have to be checked and probably changed
to avoid regressions.

Never having made that typo, I find it hard to consider such a change worth the trouble, but it sounds doable.

Regards, Jonathan