uh oh, this affects link deps
authorJoey Hess <joey@gnu.kitenet.net>
Mon, 5 Oct 2009 21:44:15 +0000 (17:44 -0400)
committerJoey Hess <joey@gnu.kitenet.net>
Mon, 5 Oct 2009 21:44:15 +0000 (17:44 -0400)
doc/bugs/bestlink_change_update_issue.mdwn

index fee65c0deaa67cc60269eaef7e31414d727618fc..211a78332b0144156b6912bee1429cce6f8d31f5 100644 (file)
@@ -1,16 +1,15 @@
 * Has bugs updating things if the bestlink of a page changes due to
   adding/removing a page. For example, if Foo/Bar links to "Baz", which is
   Foo/Baz, and Foo/Bar/Baz gets added, it will update the links in Foo/Bar
-  to point to it, but will forget to update the linkbacks in Foo/Baz.
+  to point to it, but will forget to update the backlinks in Foo/Baz.
 
-* And if Foo/Bar/Baz is then removed, it forgets to update Foo/Bar to link
-  back to Foo/Baz.
+* And if Foo/Bar/Baz is then removed, Foo/Bar gets a broken link,
+  instead of changing back to linking to Foo/Baz.
 
-As of 1.33, this is still true. The buggy code is the %linkchanged
-calculation in refresh(), which doesn't detect that the link has changed in
-this case.
+This old bug still exists as of 031d1bf5046ab77c796477a19967e7c0c512c417.
+and now this same problem also affects link dependencies.
 
-Still true in 1.43 although the code is much different now..
-
-> Still true as of 031d1bf5046ab77c796477a19967e7c0c512c417, 
-> and now this same problem also affects link dependencies.
+(Some of) The buggy code is in `find_changed_links`
+which doesn't detect that the link has changed in
+this case, because when it looks at where the `%oldlinks` link to,
+it does so after having updated state to add/remove the page.