From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Thu, 17 Sep 2009 22:51:47 GMT
Subject: Re: [PATCH JGIT] Circular references shouldn't be created
Message-ID: <200909180051.47794.robin.rosenberg@dewire.com>
In-Reply-To: <32541b130909171440w1a6d2394t4acc6a2f791c143@mail.gmail.com>

torsdag 17 september 2009 23:40:12 skrev Avery Pennarun <apenwarr@gmail.com>:
> On Thu, Sep 17, 2009 at 3:23 PM, Sohn, Matthias <matthias.sohn@sap.com> 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