From Oskari Pirhonen to ~sircmpwn/sr.ht-discuss
On Fri, Nov 10, 2023 at 09:24:10 +0100, Drew DeVault wrote:
> I like the idea. Think you can whip up a patch?
I can try, but I'll be on vacation for the next 2 weeks. If someone
beats me to it, that's fine too.
- Oskari
From Oskari Pirhonen to ~sircmpwn/sr.ht-discuss
Hi, Currently it looks like git.sr.ht only has the repo + the file/dir in the page's title. I think it would be useful to also show the branch name so that it's easier to tell, for example, by hovering over the browser tab which version is currently open. As a more concrete example, assume there exists a repo with two branches: master and cool-feature. If I open a file from both branches in separate tabs, the titles both look like this: ~user/repo: some/file - sourcehut git ~user/repo: some/file - sourcehut git
From Oskari Pirhonen to ~sircmpwn/sr.ht-discuss
Hi, Currently when browsing a repo on git.sr.ht the commit that is shown/linked in the bar at the top seems to always be the latest one on that branch. Would it be possible to make that instead be the latest commit that touched the file/directory that is currently being viewed? That would be more useful information IMO. - Oskari
From Oskari Pirhonen to ~sircmpwn/sr.ht-discuss
On Sat, Jul 15, 2023 at 14:04:24 +0200, Drew DeVault wrote: > This is just a matter of this git operation being expensive. It's slow > when you run git on localhost, too. Fair enough. I suppose something like GitHub is able to precompute/cache results like that which makes it much faster. Or maybe it's javascript trickery to make it look faster by continuously feeding data. Maybe a bit of both. I'll take "usable in links(1)" over "bogged down by javascript" any day though ;) - Oskari
From Oskari Pirhonen to ~sircmpwn/sr.ht-discuss
Hi, I've noticed that the web interface can be really slow to bring up the git log of individual files/directories. It's not so noticable on small repos, but for example, on this repo/directory [1] I measured it with a stopwatch a few times and it takes ~40 seconds for the log to appear. Viewing the entire log for a branch is as fast as expected. As is viewing the log for a directory where there are enough entries for it to split it into multiple pages [2]. Is it perhaps waiting until there's a pageful of log entries or the entire log has been traversed (whichever comes first) before displaying any results?
From Oskari Pirhonen to ~sircmpwn/sr.ht-discuss
On Wed, Apr 12, 2023 at 10:36:38 +0200, Drew DeVault wrote: > It's disabled because submitting unattended shell: true jobs will cause > the build image to run for its full maximum duration of 4 hours, which > is 4 hours of build time no one else can use that build slot for. > Ah yeah, I didn't think of that. I had, perhaps wrongly, assumed that "I want a shell" implies "I will use the shell". But I can see how something like quickly rerunning your last `git` command might end up with lots of (unintentionally) idling jobs. > I'd recommend using hut(1) to submit your manifest after a push if you > want to grab a shell with it.
From Oskari Pirhonen to ~sircmpwn/sr.ht-discuss
Hi, I noticed that on `git push` I get the following message when I have "shell: true" in a build manifest: remote: Notice: removing 'shell: true' from build manifest After searching for a bit I found this [1] which says that it's been disabled for auto builds because it's a debugging feature. Which I agree it is. Is there any chance of adding an option similar to `-o skip-ci` which would disable stripping the "shell: true"? I would find it useful when working on build manifests to get shell access after a push even when it
From Oskari Pirhonen to ~sircmpwn/sr.ht-discuss
On Sun, Mar 26, 2023 at 21:18:26 +0200, Drew DeVault wrote: > Only the default branch shows in the summary page. Alright. On Sun, Mar 26, 2023 at 21:39:14 +0200, Страхиња Радић wrote: > On 23/03/26 02:17PM, Oskari Pirhonen wrote: > > New here. I pushed a repo to git.sr.ht which has 2 branches, main and > > usage, but only "main" shows up in the "refs" column of the repo summary > > page. They both show up in the refs page though. Is this expected > > behavior, or should they be auto-populated in the summary? > > > > In case it matters, the "usage" branch doesn't have any upstream set. >
From Oskari Pirhonen to ~sircmpwn/sr.ht-discuss
Hi, New here. I pushed a repo to git.sr.ht which has 2 branches, main and usage, but only "main" shows up in the "refs" column of the repo summary page. They both show up in the refs page though. Is this expected behavior, or should they be auto-populated in the summary? In case it matters, the "usage" branch doesn't have any upstream set. The repo in question: https://git.sr.ht/~xxc3nsoredxx/stdc - Oskari