gitk: Add user preference to hide custom references

[salty-horse]

External tools such as Jujutsu may add many references that are of no interest to the user. This preference hides them.

The non-custom refs are those that pass git's default decoration filter (see set_default_decoration_filter).

The preference is off by default, maintaining current behavior.

[ilyagr]

I haven't reviewed the PR yet, but I did

Update: I just filed a similar FR #17 with some thoughts. Thank you for working on this!

The PR works for me except for #18. I had to manually add the option into my config file. Update 2: Now that I realized that deleting the config file is a workaround for #18, I tested that this fully works.

Ideally, I think this would be a View option and more flexible, as I discuss in #17, but this PR is much, much better than nothing. Also, there's precedent with the hide_remotes option.

I'll certainly be using this PR from now on. Thank you again!

[salty-horse]

Closing. See discussion in #17.

[salty-horse]

I missed that refs/bisect is shown by default in Git. Can you point me at the code? I might have missed some more.

I based the list on Git's set_default_decoration_filter function, which does this:

/*
 * No command-line or config options were given, so
 * populate with sensible defaults.
 */
for (size_t i = 0; i < ARRAY_SIZE(ref_namespace); i++) {
	if (!ref_namespace[i].decoration)
		continue;
                                                         
	string_list_append(include, ref_namespace[i].ref);
}

and ref_namespace doesn't mention BISECT:

enum ref_namespace {
	NAMESPACE_HEAD,
	NAMESPACE_BRANCHES,
	NAMESPACE_TAGS,
	NAMESPACE_REMOTE_REFS,
	NAMESPACE_STASH,
	NAMESPACE_REPLACE,
	NAMESPACE_NOTES,
	NAMESPACE_PREFETCH,
	NAMESPACE_REWRITTEN,

	/* Must be last */
	NAMESPACE__COUNT
};

[j6t]

refs/bisect appear when a bisection is in progress. Obviously, git log does not show them, but Gitk does. It's helpful when Gitk shows them after git bisect visualize is invoked.

Git marks some namespaces as "decoration" here. Those not marked as decoration are filtered out by default.

This reminds me that I also like to see refs/rewritten. They occur during git rebase --rebase-merges.

Hm, aren't we entering personal preferences again?

[salty-horse]

I added bisect/* (I think it should be shown by default in Git as well), and I changed the code to use a filter_ref function (from my other patch), which can later be extended to support user-provided include/exclude lists.

Do you have a better name for the setting "Hide custom refs"?

[ilyagr]

Do you have a better name for the setting "Hide custom refs"?

You may have already seen these, but if it helps to seed ideas, I'll quote myself from #17 (comment)

Perhaps "custom ref types" is better than "custom refs"? Some other options that came to mind: "other refs" (only loosely correct, but still), "unknown refs", "unknown ref types", "non-standard refs".

From the above discussion, another possibility is to have two new checkboxes: "other decoration refs" and "non-decoration refs".

[j6t]

My initial suggestion was to call this option "Hide non-standard refs" with the definition that "standard refs" was everything that Git knows about.

I have seen this mysterious submission that adds an option to hide refs/prefetch/*. I intended that this solution here would be extended to treat prefetch refs as "non-standard".

But now I see that prefetch refs are actually "standard" by this definition, and the cited case would not be subsumed by this solution here if we take the definition literally.

On the other hand, "bisect" refs would be "non-standard" by the same definition, yet we must never hide "bisect" refs, hence, it cannot be affected by this option.

My conclusion is that we need a more customizable solution. Or am I overthinking things here?

[salty-horse]

I'm fine with making this customizable, just let me know where in the UI it should go (global settings? View?), and which command-line flags should be supported.

Found a Stack Overflow complaint from 2 months ago about Gitk showing prefetch refs.

Whatever name and option is chosen, it should have sensible defaults (and I think hiding those refs should be turned on by default, like Git does). Exceptions can be provided in a list.

[j6t]

I would provide an edit box in the global preferences labeled Hide these references (pattern): The default setting is such that users who have not changed the setting do not observe a change in behavior. Whether the edit box is a single line with space-separated content or multi-line with patterns on lines I cannot tell without seeing the result first.

In a subsequent step, the option Hide remote refs can perhaps be subsumed into this option.

The setting would only influence the operation of proc readrefs, but not any command line options.

[salty-horse]

Is it important to you to preserve the current behavior of showing all refs? My hunch is the vast majority of users would prefer sensible defaults.

Let's say the exclude list is is a one-line input field that's comma-separated. How can that syntax be communicated to the user?

(I prefer one-line to multi-line because I don't want the preferences window to grow in size to include a large empty input box, but maybe there's a better way to implement that.

[j6t]

Is it important to you to preserve the current behavior of showing all refs? My hunch is the vast majority of users would prefer sensible defaults.

It is important to preserve the current behavior. Consider a user who types gitk --all and then wonders why there are a lot of unlabeled branch tips.

Let's say the exclude list is is a one-line input field that's comma-separated. How can that syntax be communicated to the user?

A would have chosen a space separated list because a SP cannot occur in a ref. How to communicate that to the user I have no good idea, tough.

[salty-horse]

Consider a user who types gitk --all and then wonders why there are a lot of unlabeled branch tips.

They'd wonder that with a default-configuration git log --all as well. On a Jujutsu-colocated repository I see a lot of blank commits. The only difference is that gitk's show-all-refs-by-default makes it easier to understand what all these extra commits are.

Both are not ideal, but it feels more natural to me to have an unconfigured gitk behave like unconfigured git, and worth a "breaking change".

In any case, I accept your decision. I'll implement an exclude list and will remove behavior of only showing "default" refs when the list is empty.

[salty-horse]

I added setting called "Refs to hide (space-separated)" - my current value for it is jj/* gitbutler/*.

I thought about adding a tooltip when you hover over the label, giving some more information about the format, but I am not familiar with Tcl/Tk.

Tried something like this, but it had no effect. Is it because this is a ttk label?

bind $page.refstohidef.l <Enter> {set status "Hover text"}
bind $page.refstohidef.l <Leave> {set status ""}

[salty-horse]

If I run gitk --all, I see Jujutsu's empty commits, but they don't have the decoration.

Perhaps this setting should also prevent --all from showing commits that are only referenced by (or are parents of) refs the user chose to hide?

[j6t]

If I run gitk --all, I see Jujutsu's empty commits, but they don't have the decoration.

Perhaps this setting should also prevent --all from showing commits that are only referenced by (or are parents of) refs the user chose to hide?

I would expect that ref enumeration works the same as with git log. If you don't want to see everything, use --branches --remotes --tags HEAD, but please don't change --all.

[j6t]

Seems to work as advertised.

But can we please have a different name instead of filter_ref? The name doesn't tell what the return value is. Perhaps is_other_ref_visible?

[salty-horse]

Renamed.