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

Order tree by size #89

Open
ccinelli opened this issue Nov 26, 2018 · 21 comments
Open

Order tree by size #89

ccinelli opened this issue Nov 26, 2018 · 21 comments

Comments

@ccinelli
Copy link

This is a great tool.
Can you add an option to order the folder structure by size?

@wagoodman wagoodman added this to the v0.5.0 milestone Nov 27, 2018
@wagoodman wagoodman modified the milestones: v0.5.0, v0.4.0 Nov 27, 2018
@darxtrix
Copy link

@wagoodman I am picking up this, do let me know if you already started working on this :)

@wagoodman
Copy link
Owner

@darxtrix haven't started yet, have at it!

@darxtrix
Copy link

Cool, thanks will send in a PR when done.

@darxtrix
Copy link

@wagoodman currently the file search is implemented at complete FileTree level and not at a particular FIleNode level, so are we going to implement the sorting operation on the FileTree level or FileNode level ? A FileTree level sort will be more resourcing consuming and I guess at a particular point users are mostly interested in sorting at a FileNode (directory).

@wagoodman
Copy link
Owner

I took this issue to be sort the current directory in the tree by size, but what you're really saying is globally sort the tree contents by size, regardless of which directory it is in? If that's true, then this is a heavier lift since it implies replacing the filetree UI (right pane) entirely.

Since each directory is showing the aggregated content size, would sorting the dir contents be good enough? Later tonight I can jump back on and go into a bit more detail.

@darxtrix
Copy link

darxtrix commented Nov 28, 2018

Sorry for late reply. Timezone issues.

@wagoodman I was trying communicate the same as you mentioned. We should sort at the directory level instead of full tree level.

We might need to put some parameter representing the total size of the directory at the FileNode level otherwise we have to traverse down recursively each time. What are your thoughts on this ? Should we have to support both ASC or DESC sort, or the DESC is sufficient ?

@darxtrix
Copy link

Hi @wagoodman, just following up. Any thoughts on this ?

@wagoodman
Copy link
Owner

Sorry for the delay, you're right about needing to add a total size parameter on the FileNode struct... I'll call it branchSize here, or the total number of bytes on this tree branch --from this node and it's children. My first thought is to populate branchSize at either FileTree.AddPath or FileNode.AddChild. The upside is that this is the only place that we are affecting the tree structure. The downside is that there may be a performance hit when calling something like FileTree.StackRange.

The next problem to solve is ensuring that there is parity with rendering the tree string. Currently it presumes that each dir contents is sorted alphabetically (https://github.com/wagoodman/dive/blob/master/filetree/tree.go#L73), so now there will need to be a way to indicate the current sort preference and reference that here.

As for ASC/DESC, I'd start with DESC for now, we can always expand it to ASC later (this becomes more of a screen realestate problem than a technical problem... the bottom hint bar that shows keybinding hints is getting full).

@darxtrix
Copy link

Cool, I will go ahead and implement this. Thanks !

@wagoodman wagoodman modified the milestones: v0.4.0, v0.5.0 Dec 2, 2018
@wagoodman wagoodman added this to the UI Enhancements milestone Mar 25, 2019
@wagoodman wagoodman removed this from the UI Enhancements milestone Mar 25, 2019
@marshallford
Copy link

I see this issue was removed from "UI Enhancements". What is the status of this? Is it just low priority?

Thanks.

@Sarke
Copy link
Contributor

Sarke commented Jun 30, 2020

@wagoodman Is this abandoned?

@wagoodman
Copy link
Owner

It seems like this specific issue is probably up for grabs, yup.

@Dunky13
Copy link

Dunky13 commented Jul 6, 2021

Would (still) be greatly appreciated in 2021 :) Love the tool 👍

@jkryanchou
Copy link

+1

@dlinning-jockey
Copy link

dlinning-jockey commented Jan 7, 2022

+1, this would be super beneificial.
Currently, I find myself going into an interactive terminal, and running something like du -sh node_modules/* | grep M to find anything that's at least a MB.

@RasmusJohns
Copy link

I'll join the choir and say that this would be a terrific feature. Also, I would like to add that dive is a fantastic tool and I truly appreciate all the work you put in.

@avramdj
Copy link

avramdj commented Jun 10, 2022

Still would be a great feature in 2022 :)

@not-poma
Copy link

In 2023 we would also really appreciate if this is implemented

@Eric-Tyrrell22
Copy link

Eric-Tyrrell22 commented Sep 5, 2023

looks like this was added in v0.11.0. If you're focused on the current layer contents pane and hit CTRL + o, it'll sort by size.

@avramdj
Copy link

avramdj commented Sep 5, 2023

Awesome, we did it guys. (by bumping a feature request for half a decade and absolutely no one making a single PR). Another win for open source 😎

@Potherca
Copy link

FYI: This issue has been resolved by #424

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

No branches or pull requests