From: Robin Rosenberg <robin.rosenberg@dewire.com>
To: Avery Pennarun <apenwarr@gmail.com>
Cc: "Sohn, Matthias" <matthias.sohn@sap.com>,
"Shawn O. Pearce" <spearce@spearce.org>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH JGIT] Circular references shouldn't be created
Date: Fri, 18 Sep 2009 00:51:47 +0200 [thread overview]
Message-ID: <200909180051.47794.robin.rosenberg@dewire.com> (raw)
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
next prev parent reply other threads:[~2009-09-17 22:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-17 19:23 [PATCH JGIT] Circular references shouldn't be created Sohn, Matthias
2009-09-17 21:40 ` Avery Pennarun
2009-09-17 22:51 ` Robin Rosenberg [this message]
2009-09-18 6:37 ` Sohn, Matthias
2009-09-18 21:20 ` Shawn O. Pearce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200909180051.47794.robin.rosenberg@dewire.com \
--to=robin.rosenberg@dewire.com \
--cc=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=matthias.sohn@sap.com \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox