Can we add a synced sign to git.yazi
Closed this issue · 22 comments
Please describe the problem you're trying to solve
It's hard to tell whether an item is synced or ignored right now. In this case, the folder a is ignored, and alacritty is synced, but there's no visible difference between them.
Would you be willing to contribute this feature?
- Yes, I'll give it a shot
Describe the solution you'd like
Add a synced sign and an ignore sign. Adding these signs would be helpful to alignment. The format on the right side looks more comfortable and organized than the one on the left.
Additional context
PS: Is the different color here intentional?
This seems to conflict with #18, cc @AnirudhG07
Any ideas on how to reconcile them?
The format mentioned on the right, does look good, better than empty actually. DreamMaoMao's git.yazi is also very comfortable in similar way.
I was just wanting that files which are in gitignore should have the ., but it was being carry forward to the src file i mentioned in my issue.(while src itself was not in gitignore).
If things could be merged, i would say keep the . for gitignore files, but it should not appear if they themselves not in gitignore, but contain files having .. Also the tick and + sign look good IMO.
I think there might have been some misunderstanding in what i meant when i said ignore is misleading. Hope it wont cause too much trouble. Please clarify further if anyone has still confusion about it.
Plus, referring #1580, the spacing issue will not too bad, with having some symbol for each case. Till now everyone has been using Mao's git.yazi, and i didnt come across any complains for it. Please think about it, I only want git.yazi to be its best!
If things could be merged, i would say keep the
.for gitignore files, but it should not appear if they themselves not in gitignore, but contain files having.
Sounds good to me. In my opinion, it should looks like this:
No, for the unignore_dir_with_all_ignore_files, it would become a bit hard to implement(?), so it would be fine without the ., cause see, you don't want to remember each time, if this has all ignored files or not. And this is exactly an example of when i meant as ignore is misleading. So IMO, ., tick or ?(whatever), tick, ? respectively top to bottom.
And this is exactly an example of when i meant as
ignore is misleading.
I might have a different feeling on 'ignore' than you. It's more like I don't care this item feeling. To me, if a directory is ignored—whether it's declared in .gitignore or all its files are ignored—the unignore_dir_with_all_ignore_files directory seems clear to me.
If we put different statuses files to unignore_dir_with_all_ignore_files, the directory's git sign will change, just like the other unignored directory.
I tested the DreamMaoMao's git.yazi, and it looks like this:
According the The PR I mentioned before, and our current discussion, clearly it needs to be personalized. So is it possible to add our own sign and color, using require('git'):setup(). So that people can configure on their own for what they find better.
@sxyazi what do you think?
I'm okay with restoring the ignore state that was removed by that PR and adding a configuration option to allow users to hide it. But I don't quite understand what the "synced" state refers to here, as far as I know, git doesn't have such a state.
If you mean marking files without any states as "synced", then I'm afraid I can't accept that. The reason is that the vast majority of files don't have a state (they're not modified, deleted, added, or in conflict), which means we'd be keeping all these file paths in the file status, this would be a waste of performance and memory, and unless there's a better way to implement this, I won't be able to accept it.
synced means the file/dir is already tracked and unmodifed. In my opinion, it's the default sign for the tracked file/dir.
What symbol does it use in git status? Is there an easy way to achieve it?
I'm afraid we can't get the commited file use git status. I look for the DreamMaoMao's git.yazi, it use this sign by default. See https://gitee.com/DreamMaoMao/git.yazi/blob/main/init.lua#L165
This is somewhat complex, and I didn't fully understand it, from what I understand now, it differs from my implementation, instead of reusing the already fetched state, it retrieves the state anew each time it enters a different directory and clears the previous state, this means it only remains effective for the current working directory and, therefore, doesn't have the memory wastage issue I mentioned, but it does have performance issues because the cache isn't reused, and you'll notice a flickering in large repository.
可能英语没表达出来我的意思？我没明白复杂或者不清楚的地方在哪里？方便的话你可以指出来，我再解释一下。
我还没仔细看这个git.yazi的代码，但是我用了挺长时间的DreamMaoMao的那个git插件，我没感觉到闪烁，可能是我对这个不敏感或者我的项目不够大（真心非抬杠），但是说实话，如果一个项目单一目录下有几千个文件的话，那闪烁就不应该是这个插件的问题了。或者我们可以保存当前目录，父目录，子目录的文件的git状态，这样是不是平衡性能和内存占用？就是感觉代码会复杂一些。但不管咋改，我都接受。实在不行我自己再改改呗，哈哈哈哈。
Sorry for my poor English. I haven't looked into the details of the git.yazi implementation, but I've been using DreamMaoMao's git.yazi for a while in work, and it works well without flickering. Could we save the git state for the parent directory, current directory, and child directory? This might help balance performance and memory usage.
This is a test using the Yazi git repository, and I noticed some flickering with a lot of tasks spawned, and ran forever:
screenshot-001999.mp4
And this is mine:
screenshot-001996.mp4
Hope this clarifies what I mean.
I tested on my computer (CPU: AMD Ryzen 5 5625U), and it doesn't seem to have as much latency as it does on yours.
_20240903_183423.webm
the plugin is meant to be fast for everyone, atleast best as possible. Yazi is meant to be fastest.
You can use ' ' instead of '', in case of spacing issues as i mentioned previously, for the looks atleast.
I am unable to suggest any ideas for improvements in implementation. I personally just dont want non-gitignore files with a .
@TobisLee I can still see noticeable layout shifts (flickering) in your video, even though it's not as obvious as mine, but it's still unbearable for me :/
@AnirudhG07 Exactly, that's why I decided to reimplement it - I want to have a simple and high-performance implementation included as a built-in plugin in Yazi.
the plugin is meant to be fast for everyone, atleast best as possible. Yazi is meant to be fastest.
In my opinion, a plugin needs functionality, easy to use more than its speed.
Never mind, I'll close this issue.
Let's keep this issue open, at least, the "ignore status" is doable. As for the "sync status", I don't mind supporting it if it can be implemented efficiently.
Since it's a built-in plugin, we always need to consider the worst-case scenario — no matter how large the repository the user opens, it should be loaded quickly and stably (without creating zombie tasks, and UI should remain stable no shifting).
Sure, I totally accept and understand. As I said, if the plugin doesn't fit my workflow, I'm willing to modify it myself. Thanks the time and patience.
I'm going to lock this issue because it has been closed for 30 days. ⏳
This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.