On Wednesday 01 March 2006 20:11, Junio C Hamano wrote:
> The latter at first sounds sane, but it has a subtle issue,
> which was what bitten me previously between heads/ and tags/.
> In that broken version, if you have a head called "dead" and a
> tag with the same name, neither was taken ("they are not unique,
> so do not take either!") and we ended up finding an object whose
> SHA1 name began with those two bytes 0xDE 0xAD. I do not think
> this has happened in the field, fortunately, but it would have
> been quite hard to diagnose.
>
> So if we were to do it, I would say do the latter, but be very
> careful to make sure you fail the whole get_sha1() when you bail
> out of the "try possible prefixes" codepath because of
> ambiguity.
Yes.
Any ambiguity is a source of confusion and user error. Better
bail out. If it is not a performance problem, it would be better
to integrate the check for abbreviated object name into the
ambiguity analysis, and not have 2 stages of searching.
It probably would be a good idea to print out the ambigous names
with the error message, so that you can copy&paste the correct
full name afterwards.
If we go for the .git/refs/remotes/... and have an ambiguity becaues
of remote shortcut names, a error message pointing at a "git-rename-remote"
command would be handy, allowing the user to cleanup the namespace.
> There may be other issues involved, but I wouldn't
> know -- I reverted the "do not take either if they are
> ambiguous between heads/ and tags/" patch primarily because of
> the reason from the above paragraph, but also did not want to
> deal with any other potential issues to keep my sanity ;-).
I think the real problem here is that names like "dead" can be interpreted
as abbreviated object name. When you introduce such a name as head or tag,
you have a potential ambiguity which can get real at any time.
Perhaps it would be good to print out a warning when the user is about to
create a head or tag name which can be interpreted as abbreviated object name?
Josef
-
: 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