Add branch as a search filter

[kblok]

It's super hard to search for something on a specific branch or tag. It would be great if we could have a filter for that.

[p0]

We've actually been discussing what the right UX should be, both for surfacing results from non-default branches and for restricting to particular branches. Certainly it seems that, for global or multi-repo searches, most users just expect to see the default branch.

What use case do you have in mind? Something like a branch:develop filter, to get results just from that branch and nowhere else? Would you ever use this without an accompanying repo: qualifier?

[jsoref]

Fwiw, I'm likely to do: org:check-spelling branch:spell-check path:.github/actions/spelling or org:check-spelling branch:spell-check-with-spelling path:.github/actions/spelling or possibly owner:jsoref branch:spell-check path:.github/actions/spelling. I suppose being able to do org:check-spelling branch:spell-check* path:.github/actions/spelling or org:check-spelling branch:spell-check** path:.github/actions/spelling would be vaguely useful (I personally hate the distinction between * and **, but if GitHub feels the need to make /s special, so be it).

I essentially am collecting a list of patterns / exclusions -- that I feed to my tooling each time it ingests a new repository. Often, I've already written a pattern for a given thing, but I don't remember which of a thousand (1300?) repos has the pattern -- and while some orgs/repositories have publicly added my tooling, most haven't, which means the HEAD branch for most repositories won't have the patterns I'm looking for.

Yes, on average, I'm never going to use it with a repo: modifier. If I knew the repo, I could just locally clone and use git grep.

[sbryan]

Trying to find results in a "next" branch for a public repo that is actively developing their new version... the only results I get seem to be from their default HEAD. In my case, I would likely be combining use with a repo: qualifier... for example:

repo:vuetifyjs/vuetify branch:next anchor

[pickypg]

The use case that I foresee users using within support organizations is that they will want to search a specific branch or tag (not at the same time and always against a specific repo). Support engineers are often asked about errors that surface in specific versions, where the code might be wildly different in the likely-unreleased code in the default branch.

repo:elastic/elasticsearch branch:8.0 blah
repo:elastic/elasticsearch tag:v8.0.1 blah

This will enable researching issues related to specific releases and quickly reviewing the relevant code instead of just the code of the product. I have to assume that's really the only reason I'd ever want to target a specific branch or tag for search because for any other reason, I'm likely looking at a PR or checking out the branch locally.

[jsoref]

Fwiw, the support organizations dealing with public repositories could cheat today by creating per release orgs and forking the repository, making their preferred branch the default, and deleting all the other branches/tags. GitHub would even make it easy to sync them via the button on the main page.

This is obviously a hack, but, I'd probably do it if I was in a support org.

[JoeZiminski]

I agree, are there any plans to implement searching on a specific branch? this is the one piece of functionality missing in GitHub that is keeping me from porting some large projects from GitLab.

[ldynia]

How does code search handles search when branch:<branch_name> qualifier is not specified? My assumption would be that it searches in repository's default branch. Can anyone confirm my assumption ?

[instanceofme]

Last time I tried, that's indeed what it appeared to do.

To clarify: branch:<branch_name> is a proposal and not something that actually works today. Currently, on code search, you can only search in the default branch AFAICT.

[ldynia]

@instanceofme Good to hear that, and thanks for clarification :)

[ghost]

@kblok @carlpett @instanceofme @sbryan @gravyboat Hi all! I thought of this idea: #16334

[ghost]

great idea!

[ghost]

Hi all! I thought of this idea: Control access to the branches of each repository - What do you all think of this idea?

ui/ux

Notes

With the branch control, you can search by branch types: public, private.

[nhed]

Just here to 👍 indexing all branches.

From search specification perspective I think it would be nice to be able to

• Specify specific branch on a specific repo (as mentioned above) as well as search across all repos (at least repos of an org).
• Specify branches with pattern (same syntax as in branch protection rules). So branch:maintenance/**/* would search all my maintenance branches but no other branches.

[djkgamc]

Is this part of the new search currently in technology preview?

[j4k0xb]

No: https://docs.github.com/en/search-github/github-code-search/about-github-code-search#limitations

We currently only support searching for code on the default branch of a repository.

[Difegue]

Just saw new search hit public beta and was hoping this'd be one of the improvements, sadly not 😿
I can understand the technological challenge in indexing all branches of large repos, but I wouldn't mind a slower search for the occasional times I need to pick up something from unmerged code.

[jsantiago611]

I'm going to second this! That'd be super helpful right about now, and slow search times would be preferable to manually digging through files.

[viluon]

That's exactly right, it doesn't need to be instant but it needs to be there.

[lobsterkatie]

Was just going to add a comment saying I'd be fine with lazy indexing, even if it means the given search takes 10 or 15 seconds (or however long).

Echoing back to the comment here, I'm not on the support team but I've found myself wanting this when poking around the repos of dependencies. We can't always update to the newest version, so it's helpful to be able to search the version we're actually using. For the ones I look at all the time, I've resorted to forking, cloning, and checking out a given release tag, but that's obviously neither fast nor super scalable.

[kpatelatwork]

This is going to be super helpful to search in a branch.

[tdtm]

This is useful to search for something in PRs when reviewing them.

It could be reasonable to only make it available in non-stale branch, if indexing volume is a concern.

[simtheverse]

Was looking for how to search on a branch and I am very shocked github isn't capable of it

[ldynia]

That's true. According to sourcegraph.com "With GitHub, only the default branch is searchable (though GitHub is planning to support branch search in the future)."

[kcarrillorhoads]

I literally was trying to roll out protection for our internal specifically named protected branches and wanted to make sure all branches in our org with this naming convention was protected.

[danielhoherd]

Searching within a branch would be great. This is especially important with repos where the branches aren't necessarily the same content, such as gh-pages branches.

A start would be letting us search the currently selected branch.

FWIW, one solution to not having branch search is forking the repo and doing feature-branch work in the fork. This isn't always available though, especially if you care about maintaining the fork relationship on GH. It's easy to clone and push to a new repo, but that GH fork relationship is broken.

[rmsutilidata]

29 Jan 2024: I tried to use this feature (searching with branch: <branch name>) today and it still doesn't exist. We are trying to change the name of a common term in our repo to better match our rebranded product name, so being able to search for the old term in the new branch would be super helpful for reviewing this PR.

[pickypg]

One trick that was mentioned by someone else is that you could fork your repo and set the PR branch as the main branch for the repo, then you would be able to search it.

[jsoref]

Yup. It's still the best solution today. https://github.com/orgs/community/discussions/8564#discussioncomment-2830645

If you only have one PR from a repo, making that branch the default branch for your repo makes a lot of sense too since it lets people see magic files like README.md as they'd be when merged.

[JohnRDOrazio]

I can see how it wouldn't necessarily make sense to index all branches, when certain branches have a short time of life. Perhaps there could be an option to explicitly enable indexing on a per branch basis (where it would be automatically enabled on the main branch), which would then allow to filter results by branch...

[IchordeDionysos]

Hmm on the other hand it could be useful for doing code reviews on feature branches!

e.g. when there is a task to remove all occurrences of component x, or to check if something was updated in all places etc.

It could be useful to search there instead of having to clone it

[JohnRDOrazio]

Yes in fact and so it would be useful to be able to enable indexing / searching on specific feature branches or development branches

[WTG-SB8]

Our main branch has readme.md and we have 1000 lines in a branch waiting to merge. I really wanna search this. Seems I have to pull it and do it in VS Code or something

[shaedrich]

In another reply, @jsoref suggested making branches searchable by pattern. This might also be an option for the settings, like (these are just examples):

main --> index
develop --> index
test/* --> don't index
feature/* --> index
release/* --> index
john-does-experiment --> don't index
support/* --> index
gh-pages/* --> index
hotfix/* --> don't index
bugfix/* --> don't index 
[other] --> don't index

[nandorojo]

I'd love to at least say the other important branches on a repo.

[jsoref]

You can easily do this. Example:
https://github.com/check-spelling-sandbox/multiple-instances-repo-0/network/members

jsoref@jsoref-mbp ~ % gh repo fork check-spelling-sandbox/multiple-instances-repo-0 --org check-spelling-sandbox
✓ Created fork check-spelling-sandbox/multiple-instances-repo-1
? Would you like to clone the fork? Yes
Cloning into 'multiple-instances-repo-1'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
From github.com:check-spelling-sandbox/multiple-instances-repo-0
 * [new branch]      main       -> upstream/main
✓ Cloned fork
! Repository check-spelling-sandbox/multiple-instances-repo-0 set as the default repository. To learn more about the default repository, run: gh repo set-default --help


A new release of gh is available: 2.44.1 → 2.45.0
To upgrade, run: brew upgrade gh
https://github.com/cli/cli/releases/tag/v2.45.0

jsoref@jsoref-mbp ~ % gh repo fork check-spelling-sandbox/multiple-instances-repo-0 --org check-spelling-sandbox
✓ Created fork check-spelling-sandbox/multiple-instances-repo-2
? Would you like to clone the fork? Yes
Cloning into 'multiple-instances-repo-2'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
From github.com:check-spelling-sandbox/multiple-instances-repo-0
 * [new branch]      main       -> upstream/main
✓ Cloned fork
! Repository check-spelling-sandbox/multiple-instances-repo-0 set as the default repository. To learn more about the default repository, run: gh repo set-default --help
jsoref@jsoref-mbp ~ % gh repo fork check-spelling-sandbox/multiple-instances-repo-0 --org check-spelling-sandbox
✓ Created fork check-spelling-sandbox/multiple-instances-repo-3
? Would you like to clone the fork? Yes
Cloning into 'multiple-instances-repo-3'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
From github.com:check-spelling-sandbox/multiple-instances-repo-0
 * [new branch]      main       -> upstream/main
✓ Cloned fork
! Repository check-spelling-sandbox/multiple-instances-repo-0 set as the default repository. To learn more about the default repository, run: gh repo set-default --help

[jsoref]

The reason for the additional org is that the gui historically didn't let you create a fork in the same owner (the gui still today doesn't seem to encourage it, although I think it might be possible by doing a move).

[danielhoherd]

It's definitely possible today to fork within an org using the web-ui, though I'm not sure when that feature was added. I was able to fork a repo within my own org, as long as I changed the name. This seems much more reasonable than replicating org team structures and access and policies and IDP configurations and and and

[jsoref]

Right. Although note that my suggestion is that the repositories not allow anything -- if at all possible, disable issues / actions / pull requests -- the only thing to use the repository for is for a bot to sync the single branch -- you could even have a bot that:

1. unarchives
2. syncs
3. archives

I believe that'd give you search indexing w/o people, on average, being able to open issues/pull requests.

(My suggestion about the extra orgs predated the ability to cleanly create multiple forks w/in the same owner... -- I'm glad to hear. & see they changed the ui to allow it as well.)

[shaedrich]

the other important branches

I'd say, that's the crux of the matter: Since the default branch (usually main or master) is the only broadly agreed upon important branch. What other important branches for other repos are, might widely differ, even though, there might be de facto standards.

This could be solved, if GitHub had a "branching mode" setting:

[mikeweilgart]

I was looking to search within a specific tagged release of our codebase. I started from a code view set to that tag, and was confused at first when search results were from the master branch, then was amazed to discover there is no feature at all to search the code at a specific tagged release. Please fix this.

[ymonye]

Please implement this. You guys are Microsoft now... you basically have unlimited money to pay devs for this feature 😅

[pierluigilenoci]

[ntfshard]

I expected much more comments in this topic

[danielhoherd]

Maybe if we tell them to solve it with AI then it will be prioritized.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[AG-w]

how come that searching in different branch is not a default feature??

[jsoref]

Indexing thousands of branches would be expensive. Most people won't search most branches which means it's a very expensive proposition.

If you need something to be indexed, you can create a fork (same owner) and change the default branch and then it'll be indexed.
https://github.com/orgs/community/discussions/8564#discussioncomment-8708140

Feel free to submit something to support complaining about copilot.

[danielhoherd]

Indexing thousands of branches would be expensive

But if we say it's an AI feature, maybe they'll decide it's worth the money.

[ntfshard]

Indexing thousands of branches would be expensive.

But they have feature to search in whole GitHub

[matbmoser]

Maybe would make sense to allow only when a repo is specified like:

repo:eclipse-tractusx/digital-product-pass tag:v4.0.1 SOME STRING

Instead of showing main it would have added the "branch filter":

[JohnRDOrazio]

It also doesn't make sense to index all branches by default. That would be very expensive and a bit useless. It would make sense to be able to turn on indexing for a specific branch, and then be able to search in that branch.

[araskachoi]

has this feature been added to github yet?

[matbmoser]

I am looking for to search by tag:v8.0.1 or branch:main

Why is this not implemented yet??? Is it not so simple? There are apis to search it by tag or branch already

[Steven-Martin-CC]

This should be a basic feature, it's been long requested. Has there been no progress?

[pierluigilenoci]

[swanson8r]

[swanson8r]

💡 Today I learned about the github.dev web-based editor public beta that offers a different workaround for searching a branch than having to clone it to a separate repo:

https://docs.github.com/en/codespaces/the-githubdev-web-based-editor#about-the-githubdev-editor

Yes it uses Vscode search syntax, but it's a start. This gives new relevance to related discussions such as https://github.com/orgs/community/discussions/8798

[danielhoherd]

I'm happy to see a workaround for a subset of the use cases, but one of the main uses cases here that is not met is searching an entire (paying) organization for problematic code, including long-running non-default branches.

[danielhoherd]

I was just hit with this again today. Somebody asked me about some documentation to add about a feature, and which versions it should be included with. I went to the GH repo for the project, switched to the branch, and performed a search... and then I remembered that searching only happens on the default branch. It's so counter-intuitive. Here I am using FOSS git CLI that has a more capable search than the enterprise git hosting that we pay for.

[girng]

yes please add this! i'm searching for reload_vram in godot's repo, and it's in the 2.1 branch but github doesn't find it. can add an option on the search dropdown to select xx branches or search in all branches

edit: or in advanced search, add option to select branches in there

[jsoref]

That's a really expensive proposition. There are way more branches / tags than repository heads. And search indexing is fairly expensive (in terms of CPU, ram, and storage) -- I'm speaking as someone who worked on a source code indexer for a number of years.

As noted, you could fork the repository you care about, change the default branch, wait a bit, and search it. For example, I've done just that in the form of https://github.com/check-spelling-sandbox/godot-2.1 -- assuming that you wanted to index https://github.com/godotengine/godot/tree/2.1.

[girng]

That's a really expensive proposition. There are way more branches / tags than repository heads. And search indexing is fairly expensive (in terms of CPU, ram, and storage) -- I'm speaking as someone who worked on a source code indexer for a number of years.

As noted, you could fork the repository you care about, change the default branch, wait a bit, and search it. For example, I've done just that in the form of https://github.com/check-spelling-sandbox/godot-2.1 -- assuming that you wanted to index https://github.com/godotengine/godot/tree/2.1.

lol cry more. that's the entire point of searching in branches. of course it's a bit more expensive, put a flood timer behind it then.

this is the entire point of this thread and you're still here defending them not adding it lmao

As noted, you could fork the repository you care about, change the default branch, wait a bit, and search it.

... we already know this

[jacksondoherty]

+1 on this feature...

[danielhoherd]

For everybody who just needs a solution, here's how to use the git command to search all branches:

git grep 'search string' $(git branch -a --format='%(refname:short)')

The output is branch_name:file_name:search string