FR: a way to hide non-branch non-tag refs in log graph view / `log.excludeDecoration ` support

[ilyagr]

Some git-adjacent tools track information with special refs that are neither branches nor remote branches nor tags. For example, in its colocated-with-Git mode, https://github.com/jj-vcs/jj creates lots of jj/keep/<hash> tags to avoid garbage-collecting commits it wants to be able to access. https://github.com/arxanas/git-branchless functions similarly.

AFAICT, one can avoid showing commits that are only reachable by such tags by setting up a view like in the screenshot below (this is great!).

Problem: However, even in that case, the long jj/keep clutter the log view of gitk (this is less good), and AFAIK there is no way to change that currently.

I'd like an option to hide those purple tags from the gitk log view.

---

Git itself has --decorate-refs/--decorate-refs-exclude options and a log.excludeDecoration config for this; I think they are relatively recent. I tried to putting --decorate-refs-exlcude=jj/keep these as "additional arguments to git log" in the gitk view config screen, but that resulted in an error: "Error reading commits: fatal: unrecogniced argument: --decorate-refs-exlcude=jj/keep".

According to my somewhat limited testing, the log.excludeDecoration config also has no effect on gitk.

So, one possible solution is to support that config and/or have some way of configuring --decorate-refs/--decorate-refs-exclude in the view configuration dialog.

---

See also jonas/tig#1172, jonas/tig#1160 for tig's approach.

[salty-horse]

I tried to putting --decorate-refs-exlcude=jj/keep these as "additional arguments to git log" in the gitk view config screen, but that resulted in an error: "Error reading commits: fatal: unrecogniced argument: --decorate-refs-exlcude=jj/keep".

You have a typo: "exlcude" -> "exclude". But in any case, it has no effect.

Gitk uses the git show-ref which is unaffected by that flag. It uses that command both to decorate commits in the main tree view, and in the "File > List references (F2)" window.

It would be nice to read Git's config and act accordingly. (If excludeDecoration isn't set, only the default known refs are included. If it is set, only the mentioned refs are excluded.) I think it's the better approach. It will change the output for those that don't have that setting, but it's the sensible choice.

I can try to implement that in a new PR, instead of #16.

[salty-horse]

Perhaps log.initialDecorationSet should be supported too, as they override each other, IIRC.

[j6t]

I didn't know about log.excludeDecoration or log.initialDecorationSet.

Since Gitk's way to display refs is different from git log, supporting log.initialDecorationSet does not make a lot of sense; the default in Gitk amounts to all, which is the opposite of git log.

But we cannot support log.excludeDecoration, either. If we did, consider a user who has set log.excludeDecoration for Gitk. Later, they set log.initialDecorationSet=all and expect git log to show all decorations. But it doesn't because some are excluded thanks to log.excludeDecoration.

My opinion is that the two systems are too foreign to be united.

[salty-horse]

How about a Gitk preference to "Respect Git's decoration settings", which would read those two settings and match git log's behavior?

Can you give an example of how these systems being "too foreign" affects user expectations? Am I missing something in thinking this would be a welcome change, enough to even be the default?

[j6t]

I thought I gave an example?

But do think that an option "Respect Git's decoration settings" could be feasible.

[salty-horse]

I thought I gave an example?

I'm sorry, if you mean "consider a user who has set log.excludeDecoration for Gitk", then I don't follow.

Assuming support for reading both relevant settings from Git's config file is added in gitk, then this isn't just "set for gitk" - it will affect both gitk and git log. I can't imagine a scenario where the user expectation isn't seeing the same thing in gitk and git log.

In other words, I think this "Respect Git's decoration settings" behavior should be the default.

[j6t]

Let me explain again why the two configs are foreign. I am talking about a world where there is no "Respect Git's decoration setting" option.

Without any configuration git log doesn't show all refs, but Gitk does show all refs.

Now, a user who doesn't want to see third-party refs in Gitk might set log.excludeDecoration, because we told them to use that setting for that purpose. This doesn't influence git log at all, because it didn't show these refs anyway. But Gitk now doesn't show them. Fine.

Now, the same user decides that they do want to see third-party refs in git log (and only in git log). So, they set log.initialDecorationSet=all, because, after all, the manual says this enables all refs. However, this doesn't work as expected, because log.excludeDecoration is already set to hide these refs.

[salty-horse]

OK, this was the miscommunication:

a user who doesn't want to see third-party refs in Gitk might set log.excludeDecoration, because we told them to use that setting for that purpose.

I'm against this. Gitk should support BOTH log.excludeDecoration and log.initialDecorationSet, not just one of them. Then it would be consistent with "git log". (I already encounted how confusing this is when I installed GitButler, it set "excludeDecoration", and suddenly my Jujutsu refs appeared in git log)

I don't think an option of "Respect Git's decoration settings" is needed, but if it exists, it should be on by default.

My previous PR #16 can be closed - I'll work on a new one.

[salty-horse]

Should these command-line options of git log also be supported? --decorate-refs, --decorate-refs-exclude, --clear-decorations.

I mean beyond the current behavior of passing them on to git log.

[j6t]

I'm actually not sure anymore that a "Respect Git's decoration settings" option is desirable. We already have Hide remote refs, it was already proposed to Hide prefetch refs, now we have another category of refs to hide or to make the setting completely customizable.

I would now prefer to have these options independent from git log settings. Then we don't have to listen to the command line options (but we still could).

[salty-horse]

How should these options be independent? An editable list in gitk preference window?

Git allows specifying multiple patterns for exclusion - would that become a comma-separated list?

Here's my WIP that supports Git's log.initialDecorationSet and log.excludeDecoration: https://github.com/j6t/gitk/compare/master...salty-horse:respect_decoration_settings?expand=1

It also has empty lists to include/exclude that are handled like git log's flags.

Should I open a PR to discuss it separately?