~xxc3nsoredxx

Recent activity

Re: git.sr.ht: Show branch in title 10 months ago

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

git.sr.ht: Show branch in title 11 months ago

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

More relevant commit info when browsing repo 1 year, 1 month ago

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

Re: Git log of individual items is slow 1 year, 2 months ago

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

Git log of individual items is slow 1 year, 2 months ago

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?

Re: shell: true removed from manifest 1 year, 5 months ago

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.

shell: true removed from manifest 1 year, 6 months ago

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

Re: Branches not showing up in repo summary 1 year, 6 months ago

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.
> 

Branches not showing up in repo summary 1 year, 6 months ago

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