Junio C Hamano wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html