Re: git-svn and huge data and modifying the git-svn-HEAD branch directly

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Mar 1, 2006, 20:54 UTC
Message-ID: <200603012154.16509.Josef.Weidendorfer@gmx.de>
In-Reply-To: <7virqyf094.fsf@assigned-by-dhcp.cox.net>

On Wednesday 01 March 2006 20:11, Junio C Hamano wrote:

Show 13 quoted lines

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

Show 5 quoted lines

> 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