Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with long file paths #25

Closed
eltoncezar opened this issue Jan 25, 2023 · 7 comments
Closed

Issue with long file paths #25

eltoncezar opened this issue Jan 25, 2023 · 7 comments

Comments

@eltoncezar
Copy link

I ran git-sim status on my repo, and this was the result:

image

@initialcommit-io
Copy link
Contributor

@eltoncezar LOL... I see how that can be a problem. Thinking about what the best way to address this... Obviously the file paths need to be truncated to a maximum length, and I think it makes sense to truncate them working backwards from the end of the filename/path. That way you will always at least see the filename itself, even if you are missing some of the beginning parts of the path which can usually be inferred.

Let me know if that makes sense - I will try and put in a fix for this later today.

@eltoncezar
Copy link
Author

eltoncezar commented Jan 25, 2023

Yeah, it's a tricky problem to address. I think that there are 3 options:

  1. Truncate the beginning: .......filename
    That will address most of the scenarios, but can be problematic if you have files with the same name, but in different folders.

  2. Truncate the ending: filename......
    That's dumb. Please don't do that.

  3. Truncate the middle: path.......filename
    That kinda solves the first option problem, but can be problematic if the path and the filename are too long, like my example.

I think that ideally, we should set a maximum length, try to keep the full filename and truncate the preceding folder structure.
What you think about it?

@initialcommit-io
Copy link
Contributor

initialcommit-io commented Jan 25, 2023

Thx for the suggestions. I think I will try out the option I suggested of setting the max length of the path and work backwards from the end of the string, that way we get as much as possible useful information for locating the file, and maximize the chance that unique parts of the path are shown.

The only scenario I think this doesn't handle is when the filename itself exceeds the max length. In that case it might be best to so something like: starting_chars_of_filename......ending_chars_of_filename

I'll let you know once I implement so that you can give it a try!

@initialcommit-io
Copy link
Contributor

I ended up doing it like this: first 5 chars + ... + last 15 chars.

This is deployed in git-sim version 0.1.5. Please upgrade using pip install git-sim --upgrade and let me know if any issues after you test.

@initialcommit-io
Copy link
Contributor

@eltoncezar Let me know when you get a chance to test this out, and if the fix works OK for you.

@initialcommit-io
Copy link
Contributor

@eltoncezar Closing since this should be fixed now. Feel free to reopen if any issues.

@eltoncezar
Copy link
Author

Thanks for the quick fix! Now it looks like this:
image

Much more manageable. But... I think it should use all the available space if possible. What do you think about it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants