Folder structure sometimes combined into 1 path

[reddwarf666]

Description

When I add a file the Gitea interface sometimes shows the full path combined in the list
Adding a file called "Send-WOL.ps1" located in my local folder "personal/powershell/wakeonlan" by executing "git add Send-WOL.ps1", commit and push I see the whole path as one. When I click on it I will be taken straight to the file. I can however step back in the folder structure piece by piece. I think the screenshot explains it better.
Adding a file (like README) to the "personal" folder eliminates that folder from being combined.

Not sure if this is intended but it confused me and I am not sure if my commit to Gitea was as it should be.

My expectation would be to click through the folder structure until I arrive at the file itself.

Screenshots

Here you see the path (2 parts) combined into 1

Gitea Version

1.23.5

Can you reproduce the bug on the Gitea demo site?

No

Operating System

Apline Docker host, MacOS client

Browser Version

Firefox 137.0.2

[lunny]

Can you push the repository to https://demo.gitea.com ? I think this is a feature rather than a bug.

[reddwarf666]

This is going to be a bit of a long post, sorry for that. Also, I kinda "abused" the demo gitea site to test things out, so expect a lot of repo's in my account 😁
I will remove them all once you have reviewed them and they served their purpose.

Ok, made an account at the demo site, created a repo called code and pushed the same structure into it:
https://demo.gitea.com/reddwarf/code

Oddly enough, this behaves as as it should or as I expect at least.

Steps I took:

1. made the repo called code
2. created a local folder on my laptop
3. cloned the repo with : git clone https://demo.gitea.com/reddwarf/code.git
4. copied the folder as I have it on my laptop to this new local folder, i.e. the same path and file
5. did a 'git add .' from the root of the new local folder
6. did a 'git commit -m "test"' to commit
7. did a 'git push' to send to the Gitea demo site

And when I go look at the repo, I see that the Gitea Demo site has the folder structure and file as I would expect and looks perfectly fine.

I started digging a bit and decided to look at what might be different. I started with looking at .gitignore and added mine to a new repo called code2. This is when I saw the folder issue appear on the site/repo.
Dug into the .gitignore and tested some theories. This is why you will see, ahem, a lot of repos called code<n> on the gitea demo site. I tested a pattern like **/.DS_Store (you will find a lot of this suggested pattern online) as well, same effect.

Long story short, the patterns .DS_Store and ._* seemed to be an issue. Well, any pattern that matches actually. In the demo site you will find that repo's code and code4 are behaving as expected, the others all have a flattening of paths issue/behavior.
I tested also with another set of patterns and bottom line is, anything I add in .gitignore that has an exclusion will cause an issue with combining/flattening paths if there is a match. A good example is repo code7 where I added a pattern of *.reddwarf. One path behaves as expected as it had no matches from .gitignore but another path, with a file in there called shouldbeexcluded.reddwarf and another called testfile.txt will again show this issue. The file shouldbeexcluded.reddwarf is indeed excluded but the path to these files is flattened again.

I have no answer on why this is all happening, all I can say and do is that this is repeatable by playing around with .gitignore and add an exclusion pattern in there. Once you have a folder with a file that matches the patter, the path will be flattened.

This makes no sense and I start to doubt if Gitea is doing this or this is a git problem, either in general or specifically on my end. A generic issue with matching patterns in .gitignore makes no sense if you think about it as 90% of people across the world using git would be up in arms about it I would imagine. So this is probably an issue specifically on my end.
Thing is, I use git on my mac and on linux and both uses show me the same results. I have a docker repo on my own Gitea where I push all docker compose config into, have been doing that for about 3 months now. There is a .gitignore in thet repo as well, because I also sometimes browse with mac finder to these folders and then macos leaves/drops these .DS_Store files in the folders so I wanted them excluded. Luckily I have no depth of folders in there, it is mostly "foldername/2 files" so no issues so far. There is 1 folder though that has a subfolder and guess what, that path is flattened.

For now I will make the call to not have .gitignore in my own repo's anymore to avoid this path flattening behavior until I find a way (and reason on why this is happening) to start using it again. I might even put my usage with git and Gitea on hold before I am to commited and start to get into a world of hurt 😀

I found an article on github from someone on what to do with .gitignore to exclude files/patterns and this is nothing new, the pattern is used and known of course, but it gives a tip on how to remove these files from your repo if they landed in there by mistake. A lot of hassle to do this but hey, it's a way out of a situation.
Article : https://gist.github.com/lohenyumnam/2b127b9c3d1435dc12a33613c44e6308

I did do a little a test on the demo repo called code6 to see if this can be fixed somehow.

Deleted the .gitignore file like so:
find . -name .gitignore -print0 | xargs -0 git rm -f --ignore-unmatch
Then commited :
git commit -m "Removed .gitignore"
And then pushed :
git push

Result was that the .gitignore was indeed removed but alas, that did not fix the folder structure issue.

I'm a bit lucky that my docker repo 'escaped' this issue and I just started creating new repo's in Gitea and cought this before I used it for months. These new repo's I can easily delete and start over, so no history lost here when I do this.

If this is not a Gitea problem but this is something on my end with how I use git then I would appreciate it tremendously if someone could tell me what I am doing wrong.

And if you need more information or more testing on my end, I'm glad to be of help and assistance of course!

Cheers!

[wxiaoguang]

It's not that complex.

In short: if there is only one sub folder in a folder, then it will be folded into one path. It behaves as most mainstream applications do.

[reddwarf666]

Ok, I had a talk with @yusing about this (shameless plug for his awesome Godoxy project 😉) and it makes 'sense' now. An empty folder will be folded (thanks @wxiaoguang for the correct terminology) as empty folders are a bit different as I expect and am used to. It 'feels' so weird to have a path/folder structure fold like that, so much so that I concluded this must be a mistake and something went wrong 😀

This is more of a git behavior I suppose as git also doesn't want to add an empty folder when you try to add/commit it. It will do this though if a child folder does have a file in it, then the empty parent folder is added but in a different way.

As for mainstream applications, I have no idea and I suppose this is correct but from my experience working on filesystems I have never had folders fold like this. Whether it was on DOS, Windows, Linux, AS400, if you want an empty folder you get an empty folder. Anyway, this is a different discussion I suppose so I'll stop about it.

Thanks for the time and attention everybody!
I will now remove the plethora of repo's I created on the demo Gitea site.

Cheers!

[wxiaoguang]

Mainstream applications, for example:

GitHub itself

VSCode

And more.

[reddwarf666]

I see, for applications using a underlying filesystem and interpreting it in the UI. Never knew or thought about that!
On VSCode for example I never encountered that behavior but that would be because I always have a file in a folder, so that makes sense.

Filesystems on the other hand, no folding that I know of 😀

Thanks!