Commit-ID in URLs by default is probably a bad idea (at least for wikis)

Bitbucket resolves HEAD to the commit-ID and adds that to all followup links on the entry page of a repository. That enforces that you stay on the same commit when clicking around, and I get that this does have a benefit, too, but it's not what you usually want nor expect at least for wikis.

Some people call that perma-linking, but a perma-link in blogs also only permanently refers to a particular post, not a particular version of it.

Having URLs for particular versions is certainly a good thing, but I think it should not be what you get by default. People will hit reload and not see the change, or people will publish such links and people visiting them will get stale content without realizing.

So, all of this is my analysis (while checking if Bitbucket is suitable for us as a wiki), and call it theoretical, but I really wonder whether whoever decided to put commit-IDs into the URLs by default didn't also do it purely on theoretical grounds.

I'm proposing one or multiple of these changes:

• link without commit ID by default (it's probably a good idea to still provide a link on each page to get the same page tied to the current commit ID in the HEAD)
• optionally add a per-repository setting to select which behaviour (with or without commit ID) should be the default
• when formatting a page for a URL with commit id, add a flashy marker to the top of the page that says "this page has been modified. [reload the newest version]" with the link or button going to the newest version (either newly resolved commit ID in the URL, or no commit ID). Care should be taken so that if you scrolls down, then hit reload, you still get to see this notification somehow (make the marker stick to the top of the window instead of the page? Use JavaScript and floating notification instead?)

I get that linking to a particular commit has the nice advantage that it will always find the page (it could have been deleted or moved for newer commits); to keep this advantage, you could track renames (git already has that functionality, you'd have to parse it and build a searchable (and perhaps incrementally updatable) data structure out of it). It may be useful to actually keep the commit-ID in the URLs and go with the notification approach suggested above.

I think the current behaviour is rather problematic for wikis, so I leave the priority at major: we will likely move our wiki elsewhere once more than 2-3 devs uses it (unless the behaviour has changed in the mean time).