"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: gotwebd permalinks
To:
nathanael@dalliard.ch
Cc:
gameoftrees@openbsd.org
Date:
Wed, 11 Mar 2026 14:24:47 +0100

Download raw body.

Thread
On Wed, Mar 11, 2026 at 02:03:23PM +0100, nathanael@dalliard.ch wrote:
> Stefan Sperling <stsp@stsp.name> wrote:
> > On Wed, Mar 11, 2026 at 01:00:53PM +0100, nathanael@dalliard.ch wrote:
> > > hi
> > > 
> > > is there a way to get a permalink to a specific file in a repo?
> > > 
> > > i've noticed that links in the web interface all include the commit
> > > hash, which makes me think this might not be currently possible or is
> > > there a workaround i'm missing?
> > 
> > The current implementation requires a commit hash. In theory we could
> > allow references to be passed instead, as is allowed on the command line.
> > 
> > We have a TODO item about redesigning gotweb URL routing, with the goal
> > of simplifying the URL scheme and avoid use of query parameters.
> > I assume we could take another look at allowing refs as part of that redesign.
> > 
> > However, without a commit hash a link to a file cannot really be permanent.
> > 
> > What should happen if the file gets deleted at some point in time?
> > 
> > What should happen if the deleted file is reinstated with different content
> > at a later point in time?
> > 
> > What should happen if the file gets replaced several times over in the
> > life time of the repository? By a file or a directory?
> > 
> > Perhaps you don't care about these cases because you'll never delete the
> > files you want to link to. But that is a specific use case, not the general
> > case which the overall design needs to cope with.
> 
> thanks for the answer. i agree that i don't have the whole picture and
> my usecase might be niche. just to be clear what i am talking about:
> 
> https://codeberg.org/OpenBSD/src/src/branch/master/bin/cat/cat.c
> https://openbsd.gothub.org/repos/?action=blob&commit=a944417af3ca44cd189efef88c2299690e2958fd&file=cat.c&folder=%2Fbin%2Fcat&path=src.git
> 
> the codeberg link always points to the newest cat.c in the master branch
> and the gothub link doesn't (at least if i understand it correctly)
> 
> i guess i am used to this from git web interfaces like cgit, stagit and
> others. but of course i understand, if that is not wanted for gotwebd
> 

I didn't mean to say it is not wanted.
The codeberg link is obviously a lot more readable and user-friendly.
I hope that gotwebd will support a similar URL scheme in the future.
There is a todo item for this. It's just a matter of someone finding
time to make the required changes while keeping the old links working.

I was just pointing out that even Codeberg could not provide a permanent
link to file content without requiring a commit hash. The behaviour of
the above codeberg link I would expect is a 404 if the file no longer
exists on the requested branch. And if the file was changed tomorrow
tben the link would return different file content than it would today.
It might even return a directory listing if a file is replaced by a
directory, or vice-versa.

I am trying to point out that this dynamic behaviour contradicts the
concept of a "permalink".

Depending on the situation, if this link is used as a reference from
somewhere else, then a future reader who follows this reference might
end up very confused if the file content has changed and no longer fits
the context the link was provided in.

While the gotwebd link will indeed always steer readers to the same file
content, provided the requested commit wasn't removed from the repository.

So if you want permalinks, we already have them. But they can only
point to one specific version of a file, of course. You would need to
update the link at the source to keep track of changes. This can be
inconvenient, but on the other hand the link won't break unexpectedly.