/refs/patches vs Git 2.38 --decorate-refs tightened namespace list

[lkraav]

We can't see refs/patches namespace in git log by default anymore because reasons explained at https://stackoverflow.com/a/73678554/35946

Patch https://www.spinics.net/lists/git/msg444386.html

While upstream strategy probably makes sense, I'm now wondering how can I simply add refs/patches namespace to the default upstream list, instead of overwriting, and thereby needing to take on syncing future upstream list changes.

[lkraav]

Could @derrickstolee perhaps comment here? I could see from patchset discussion core|xyz type filtering never made it.

[derrickstolee]

I'm sorry that this change caused a disruption to your workflow. As mentioned in other comments, log.initialDecorationSet can solve this problem for you, and was its intended purpose. Extending Git to include a log.includeDecoration would be an interesting way to help your use of extra refs like this.

For now, you might notice some refs/prefetch or refs/bundles refs show up (depending on your use of background maintenance or bundle URIs) when using log.initialDecorationSet=all without using log.excludeDecoration to clear those out.

[lkraav]

Thanks. We'd appreciate if you'd consider patching log.includeDecorations in at one point.

[jpgrayson]

Thanks for opening this discussion @lkraav. I hadn't noticed this change until now.

I note that there is a log.initialDecorationSet config value that can be set to all to restore the previous behavior of decorating with all refs. Reverting to the old behavior by setting:

git config --global log.initialDecoractionSet all

is probably sufficient for my use cases, but it might also be nice if there was a log.includeDecoration config value to complement log.excludeDecoration.

[lkraav]

Yep, log.initialDecoractionSet all is what I'm doing right now, too. Hopefully Derrick will see this mention and chime in eventually.