Skip to content

gitk: new option to hide prefetch refs #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

rappazzo
Copy link
Contributor

@rappazzo rappazzo commented Jul 7, 2025

The maintenance 'prefetch' task creates refs that mirror remote refs, and in repositories with many branches this can clutter the commit list.

Add a new option to ignore any prefetch refs, enabled by default.

--

This was authored by @hasturkun and submitted to the git email list several years ago. It was never brought into the upstream for whatever reason, but likely due to the process for getting changes to gitk at the time.

I have been rebasing and patching this change to my locally installed gitk script ever since this code's submission to the git email list.

The maintenance 'prefetch' task creates refs that mirror remote refs,
and in repositories with many branches this can clutter the commit list.

Add a new option to ignore any prefetch refs, enabled by default.

Signed-off-by: Tal Kelrich <hasturkun@gmail.com>
Signed-off-by: Michael Rappazzo <rappazzo@gmail.com>
@j6t
Copy link
Owner

j6t commented Jul 7, 2025

Prefetch refs are not the only refs people want to hide. Please have a look at PR #16 if it would satisfy your needs. It adds an edit box where you can specify patterns which refs to hide.

@rappazzo rappazzo closed this Jul 7, 2025
@rappazzo
Copy link
Contributor Author

rappazzo commented Jul 7, 2025

That seems reasonable and much more flexible. I've withdrawn this pull request.

@rappazzo
Copy link
Contributor Author

rappazzo commented Jul 9, 2025

@j6t I have another patch that I was basing on this change due to conflicts. Is #16 likely to get in? I can rebase my patch on that if so.

@j6t
Copy link
Owner

j6t commented Jul 10, 2025

You should base your patch on another PRs only if the other PR is a prerequisite for your change. A conflict is not an indication of a prerequisite.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants