torsdag 17 september 2009 23:40:12 skrev Avery Pennarun <apenwarr@xxxxxxxxx>:
> On Thu, Sep 17, 2009 at 3:23 PM, Sohn, Matthias <matthias.sohn@xxxxxxx> wrote:
> > void link(final String name, final String target) throws IOException {
> > + if (name.equals(target))
> > + throw new IllegalArgumentException(
> > + "illegal circular reference : symref " + name
> > + + " cannot refer to " + target);
>
> This isn't a very thorough fix. It doesn't catch longer loops, like
>
> HEAD -> chicken -> HEAD
>
> or
>
> a -> b -> c -> d -> a
>
> Experimenting with original git.git's implementation, I see that this
> is allowed:
>
> git symbolic-ref refs/heads/boink refs/heads/boink
>
> It succeeds and creates a file that looks like this:
>
> ref: refs/heads/boink
>
> And "git show-ref refs/heads/boink" says: nothing (but returns an error code).
>
> And "git log refs/heads/boink" says:
>
> warning: ignoring dangling symref refs/heads/boink.
> fatal: ambiguous argument 'refs/heads/boink': unknown revision or
> path not in the working tree.
> Use '--' to separate paths from revisions
>
> Clearly, in git.git, symref loops are caught at ref read time, not
> write time. This makes sense, since someone might foolishly twiddle
> the repository by hand and you don't want to get into an infinite loop
> in that case. Also, it's potentially useful to allow people to set
> invalid symrefs *temporarily*, as part of a multi step process.
I had already written a patch much like this when I decided we need to do much better.
I think we should do this in the UI by not allowing the user to make a
choice that would result in a loop and fixing the way the UI resolves
choices. When creating a new branch we should analyze the selected
ref and dereference it if it is a symbolic name like HEAD or if it is a tag,
and perhaps show it like "HEAD (refs/heads/master)" in the the dialog.
Using unresolvable refs as the base for a new branch should be disallowed.
-- robin
--
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