---
 pager.go | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/pager.go b/pager.go
index 7b8b6d0..b5cbb39 100644
--- a/pager.go
+++ b/pager.go
@@ -19,7 +19,11 @@ func newPager() pager {
 		return &singleWritePager{os.Stdout, true}
 	}
 
-	cmd := exec.Command("less")
+	pgrcmd, ok := os.LookupEnv("PAGER")
[message trimmed]

On Sun, Jul 16, 2023, at 00:54, Oskari Pirhonen wrote:
> 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.

They cache. The reason Git's slow here is that it doesn't store what files are changed in a given commit, so you have to repeatedly load a commit, check whether the file was modified by loading all intermediate trees and then comparing shas, noting the history if it's different, and then repeating for any parent commits, until the file finally isn't in the history. There are tons of no-ops in that sequence, and lots of unpredictable disk seeks and disk reads.

What e.g. Kiln used to do was just log, during push, what files were touched by what commit, and then generate the file history via database query (rather than Git). GitHub does something similar. There's definitely nuance to this (file history is head-specific, force pushes can *delete* history, etc.), but it's tractable, fairly straightforward, and worth it if you're dealing with large repos or lots of file history views (especially if you want to have quick access to blame, which otherwise is everything I just said, *plus* repeated diff checks).

On Wed, Jul 5, 2023, at 04:29, Brad Clawsie wrote:
> Since everyone else seems to be managing, its clearly a config/locale 
> or some other issue on my end.
>
> Thanks for the replies everyone!

Bit of a wild guess, but are you on Windows, maybe in one of the native shells? I'm wondering if the extra newlines are being injected in one of the pipes.

I’ve got two comments on the pricing model, which are less about what 
I want, and more just business experience from my past ventures.

On 13 Feb 2020, at 13:10, Drew DeVault wrote:

>     Payment
>
> I'm open to suggestions here, but here's the general plan:
>
> Organizations will be able to sponsor the accounts of their members.
> They can also have members who have paid for their own account
> participate in the group without an additional charge.

This doesn’t make much sense to me, from two angles.

On Wed, Sep 25, 2019, at 10:59, Drew DeVault wrote:
> Perhaps the patch belongs in Mercurial, then. After all, Unix files end
> in newlines.
> 

Windows ones generally don't. It'd be unfortunate if Sourcehut cut out shops that need to work with Windows and need accurate patches.

On Wed, Sep 25, 2019, at 09:39, Drew DeVault wrote:
> Can you prepare a patch for libgit2 instead?

I've historically found their team uninterested in supporting changes that applied to non-Git SCMs. And more transparently, I think that's correct: Git patches do, as far as I know, always end with newlines; Mercurial's don't if the file itself lacks a final newline and the patch applies a diff to the end of the file. I'm not clear libgit2 ought to handle the latter case natively, nor do I think either of these approaches is intrinsically correct.