Duplicate filenames differing only in case in markdown/security-management/ - breaks git clones on case insensitive filesystems (mac os)

[bikemeardsley]

The australia branch contains two files at paths that differ only in the case of letters in the filename:

• markdown/security-management/get-IP-from-CI-activity.md — blob 5c7670474, older "workflow activity" wording
• markdown/security-management/get-ip-from-ci-activity.md — blob 5e575bc9f, newer "flow activity" wording with a Results section, generalized input/output variable descriptions, and the Exit Conditions section removed

Both render directly on GitHub:

• https://github.com/ServiceNow/ServiceNowDocs/blob/australia/markdown/security-management/get-IP-from-CI-activity.md
• https://github.com/ServiceNow/ServiceNowDocs/blob/australia/markdown/security-management/get-ip-from-ci-activity.md

git can only check out one of these files to the working tree, both paths collide. Whichever file is written second wins on disk, and the other appears as a permanent local modification in git status, even on a brand-new clone. git restore does not resolve this; it just flips which entry appears modified. Users on case-sensitive Linux do not see the problem.

[ekimbernow]

This must be an issue in our source--difference case for the references. This is always a struggle for us to manage because while we have a "only use lowercase" rule for writers, we have some topics that must have mixed case (mostly API topics, where the filename exactly matches the method name). So it's hard for us to police.

I'll see if I can find the cause in the source and fix it.

[ekimbernow]

It also didn't occur to me that somebody would clone the repo locally but I guess that could be useful maybe. But it's definitely not intended for local use.

[ekimbernow]

I found the source issue: Two topics in different directories with filenames differing only in case. Because our source organization is different from the as-published organization, you get the names differing only in case in the markdown.

It's still an authoring error but a subtle one.

[bikemeardsley]

A local clone with occasional pulls to stay up to date was the recommendation provided to me by leadership since it is cheaper/faster to have claude perform local md file operations instead of call out to the github repo each time. And we can't use the claude github connector so this is the next best way to easily access the docs in their entirety

[ekimbernow]

Interesting. How does Claude handle the absolute URLs back to github? Or is it not using the links and just looking at everything?

[bikemeardsley]

Good question, I just tried it out and I believe it just doesn't use the absolute URLs locally. Claude reads files directly via the filesystem rather than following any URLs. How I set my Claude up is to periodically git pull the SN Docs repo to stay current, and then I gave it filesystem access to read the local cloned folder. Seems to work pretty well so far

[ekimbernow]

Good to know it works as is.