In Codeberg, how does one even search for files containing a given string? Probably the #1 thing I do on GitHub is searching for files in a project containing a given string.

Given how terrible GitHub search in files is, what I usually do is clone the repo and run ripgrep.

If the repository is indexed, there isn’t really competitive search. You can find blog posts about it. They actually used ripgrep at some point. (not anymore I guess because too slow?).

Edit: ripgrep was just a test

More: https://github.blog/engineering/the-technology-behind-github...

Not sure when you tried last, but it's gotten a lot better over the years. If you need something from the latest master, you'll be able to find it.

But Github is actually pretty good at searching for something across all files in a repo.

Not remotely as good as grep.app.

I was shocked at how fast I was able to find "Open an audio file and read as mono waveform, resampling as necessary" of whisperX in audio.py on grep.app.

It was instantaneous. But where do I go from there? I cannot navigate through the code. It shows me where I can find that string, but that's it. I also cannot look at blame to see when that line got edited.

Though thanks a lot for bringing this onto my radar.

I'm not being sarcastic but how do you do it on github?;) it basically never works

Not only results are incomplete but it seems once they went into training LLMs on all code they host they made sure no one else can do the same easily and so now everything is madly rate limited.

Every time I just clone and grep.

That exact exercise filled a quarter of my workday today.

I think it would be great if git have some kind of soft lock by default (like attach a text on some file without make it into actual commit). It could probably make peoples' live easier when you and teamates need to communicate what files you are changing thus reduce the chance of conflict.

FWIW git lfs does have support for locking files.

Yeah, especially binaries.

Git should have issue support or something like it as a convention but pull requests are an abomination that we are stuck with. No thank you.

Not Git, but several forges are working towards an ActivityOub based federation format for these: https://f3.forgefriends.org/

Git was invented with pull requests in mind. It's just that they were originally meant to be sent via email, not on the web.

Can you expand on that? I’m probably younger but I can’t imagine a more comfortable way to review code.

Pull requests are great, but the typical github UI isn't necessarily the best way to review code.

It's often useful. But sometimes you want to use other tools, like firing up your editor to explore.

No, they're terrible. We should be reviewing stacks of commits not branches

Why? A branch is a stack of commits.

The workflow I believe they're talking about is like a branch but you can have multiple versions of the branch as you develop and refine it.

And those updates are properly tracked by your version control, not done jankily by editing a commit and rebasing and force pushing.

Then whence merge commits?

A branch is a commit with a hat on, strictly speaking.

Yes, a branch together with information about the intended point of divergence is a stack of commits. (Most of the time, the point of divergence is arrived at implicitly by specifying the intended mother branch, and git figures out the last common ancestor, ie the merge-base.) Let's call the branch-plus-point-of-divergence a 'PR branch'.

Though your 'stack of commits' is more like a 'stack of diffs' (at least in the Git sense of commit-is-a-snapshot-of-the-whole-repo.)

And actually, for better or worse, a PR branch is more expressive than a 'stack of commits', exactly for the reason you suggest: a PR branch can also contain merge commits, it doesn't have to be a linear chain.

They are often called stacked diffs yes.

Basically in terms of git speak branches are mutable pointers to immutable commits. (They are basically the only mutable thing in git.)

What you'd need to do to support 'stacked diffs' or 'stacks of commits' is to keep a history of what you mutable pointers were doing. It's a 'meta-git'.

Once you have that, you could build all the convenient operations on top of that abstraction.

Btw, if memory serves right, git has some plugins (or whatever these things are called, plugins or so?) for implementing the stack of commits concept.

I don't know whether they go the 'meta-git' route that I sketched, or whether they do something less abstract.

It’s only good if you haven’t tried anything else. Check out gerrit, but there are many more tools and workflows.

Note we’re talking about the GitHub UI mostly. Pulling and merging a remote branch is a basic git operation, almost a primitive.

Phabricator.