Wait, this is drifting off-topic, but:

On Wed, Sep 11, 2024, at 05:54, Aleksey Kladov wrote:
[snip]
> Speaking of checking history --- this review flow synnergises with
> magit _exceptionally_ well. This is how my review interface typically
> looks:
>
> ![](https://github.com/user-attachments/assets/0bfb3ecf-5312-4121-bb2f-3670ca52be14)

...are...are you running Emacs inside the Visual Studio Code terminal purely for Magit?...

On Wed, Sep 11, 2024, at 05:54, Aleksey Kladov wrote:
> Thanks for writing https://www.bitquabit.com/post/how-i-do-github-prs/
> down! This is _exactly_ how I do code reviews! 

Thanks!  This was a post where I wasn't sure how much I was just writing it to my future self.  I've been happy that it seems to have resonated with some people.

> For checking stuff out locally, I use the following script:
>
>     fn pr(&self, pr: &str, review: bool) -> anyhow::Result<()> {
>         let remote = self.remote;
>         let main = self.main_branch;
>         cmd!(self.sh, "git fetch {remote}").run()?;
>         cmd!(self.sh, "git fetch {remote} refs/pull/{pr}/head").run()?;
>         cmd!(self.sh, "git switch --detach FETCH_HEAD").run()?;

On Mon, Sep 2, 2024, at 15:35, Zack Weinberg wrote:
> Do you know for certain that at present there is no other way to do this?
>

Just in case: if this is because you accidentally pushed a secret, you should consider it already leaked. Even if the repo were fully deleted, you can't know whether it's in a Sourcehut backup or the like. I'm only mentioning this because, as a former source hosting admin, I know what usually prompts these requests.

If that's *not* why you're asking, I'm curious how the blob would leak at this point unless you already know the SHA. I don't *think* contemporary Git ships packfiles of more than you asked for, but I may be misremembering.

Hello to anyone who's actively using hsh!

I wanted to let y'all know that there are several incompatible updates coming in hsh 0.2.0:

  * hsh will no longer assume that it owns an entire repository. Instead, it will look for a .hsh file
    to govern the root on initial clone or linking.  This also means that it should become possible
    to have a hsh notebook inside a Git repo you're using for other things, or to have multiple hsh
    notebooks in a single repo. I'll make a command in hsh 0.2.0 that adds a .hsh file if it's missing,
    but I don't plan to have that command survive into 0.3.0.
  * hsh will begin creating new documents purely based on ULIDs (https://github.com/ulid/spec), not
    pure datestamps.  Because the creation date can be extracted from a ULID, hsh will still be able
    to tell you when a note was initially created.

This last bit is a bit of an RFC: I want to get rid of nb's concept of stable index numbers, but I

On Sun Aug 4, 2024 at 7:41 AM EDT, Robin Jarry wrote:
> Benjamin Pollack, Aug 04 2024:
> > Unfortunately, since this got applied, aerc is unable to load my Fastmail
> > account.  The logs are filled with:
> >
> > json: error calling MarshalJSON for type *jmap.Invocation: json: error 
> > calling MarshalJSON for type jmap.ID: invalid ID: too short
> >
> > I did confirm that this patch specifically is the source of the problem.
>
> You will need to delete your cache.
>
> rm -rf ~/.cache/$account_name

On Sat Aug 3, 2024 at 2:23 PM EDT, Robin Jarry wrote:
> Tristan Partin <tristan@partin.io> wrote:
> > Fetch an email's entire thread in the JMAP backend.
> >
> > Changelog-added: Fetch entire threads in the JMAP backend.
> > Signed-off-by: Tristan Partin <tristan@partin.io>
> > ---
>
> Acked-by: Robin Jarry <robin@jarry.cc>
>
> Applied, thanks.

Unfortunately, since this got applied, aerc is unable to load my Fastmail
account.  The logs are filled with:

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