mirror of
https://github.com/initialcommit-com/git-sim.git
synced 2026-04-27 03:25:53 +03:00
[GH-ISSUE #25] Issue with long file paths #20
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/git-sim#20
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @eltoncezar on GitHub (Jan 25, 2023).
Original GitHub issue: https://github.com/initialcommit-com/git-sim/issues/25
I ran
git-sim statuson my repo, and this was the result:@initialcommit-io commented on GitHub (Jan 25, 2023):
@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 commented on GitHub (Jan 25, 2023):
Yeah, it's a tricky problem to address. I think that there are 3 options:
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.
Truncate the ending: filename......
That's dumb. Please don't do that.
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 commented on GitHub (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_filenameI'll let you know once I implement so that you can give it a try!
@initialcommit-io commented on GitHub (Jan 26, 2023):
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 --upgradeand let me know if any issues after you test.@initialcommit-io commented on GitHub (Jan 27, 2023):
@eltoncezar Let me know when you get a chance to test this out, and if the fix works OK for you.
@initialcommit-io commented on GitHub (Jan 29, 2023):
@eltoncezar Closing since this should be fixed now. Feel free to reopen if any issues.
@eltoncezar commented on GitHub (Jan 30, 2023):
Thanks for the quick fix! Now it looks like this:
Much more manageable. But... I think it should use all the available space if possible. What do you think about it?