Hide branches without any metric values

[aguschin]

In case there a lot of branches which have nothing related to dvc, View becomes very polluted. If I not mistaken, you can't do anything useful or get any useful information from these branches (though maybe having .dvc in the default repo branch allows to track metrics in files in other branches, IDK about this).

To get an example, import this repo: https://github.com/iterative/yolov5 Or see the View https://studio.iterative.ai/user/aguschin/views/yolov5-ypd0c4rbtj

It has only one branch which has .dvc and dvc.yaml and it is shown at the bottom.

My guess that it should be related to https://github.com/iterative/viewer/issues/1372

The current situation in which this situation happened: there was a large repo on which dvc was applied. To try out dvc, one specific branch was created.

Also, if there are situations in which these branches could be useful, we can hide this option in Settings.

[shcheklein]

@aguschin thanks, makes total sense to me that we need to hide them by default.

[Suor]

This is only the case if the default branch doesn't have .dvc or only get it recently. Not very common scenario.

[Suor]

A way to hide branches would be helpful though disregarding whether they have any data or not. You may give up on many older branches but never delete them.

[mvshmakov]

In order to proceed with this issue, it is better to start with just the ability to collapse a branch. Currently, we have an internal design story about it https://github.com/iterative/viewer/issues/1472, but no progress so far. Should we reprioritize this one and let a designer know that is more of a priority? CC @shcheklein

[shcheklein]

Can we do something quick here @arcticbear @yalozhkin ?

To collapse commits with a branch we can reuse more commits message that we already have? WDYT @mvshmakov ?

To collapse branches we can do something similar - more branches I think.

Question here is how do they behave when filters or search are applied. Probably we need a different mode to search all or something.

[Suor]

more commits is an extra line, I would prefer collapsed branch use space at the right of its name instead - that one is not used anyway.

As collapsing a branch looks like the most useful part of this I suggest fast track it and decide on the rest later. Collapsed status should be remembered though, otherwise it would be boresome.

P.S. Hiding branch may be a viable alternative to collapsing, this also won't require "collapsing branches". Might need more design though for a user to be able to unhide them.

[shcheklein]

We should though collapse certain branches automatically also.

But I agree that mechanism itself to collapse them is probably the first step here.

[arcticbear]

This might be a good feature to minimize the noise in the table. Take a look at the idea below. I've tried to add the small arrow buttons to the left of branch titles with folded and unfolded states. I think this would work. WDYT?

Full table view example

[Suor]

@arcticbear Looks good for single or several collapsed branches. I see an issues though - if there are dozens or even hundreds of collapsed branches, say automatically, then it won't do. This is why this issue was initially about hiding not collapsing probably.

[arcticbear]

@Suor Yeah got it. This might be the first step, I'll prepare further examples of how we can hide the branches (with UI elements for noticing that to users and with the possibility to show/hide maybe).

[tapadipti]

Below I have tried to organize my thoughts/ideas around collapsing and hiding branches/commits. Pls review/comment.

Hiding commits and branches:

• If a branch does not have .dvc in the latest commit, hide it by default. All other branches should be shown by default. However, if custom metrics/plots/params have been defined for the view, then do not automatically hide branches without .dvc.
• If a commit does not have any metrics, hide it by default.
• If a commit does not have any changes in metric values compared to the previous commit in the same branch, hide it by default.
• If a commit does not have changes in params, data, and source code (at least pipeline dependencies), hide it by default.
• Add two action buttons, (similar to Show plots), for Hide commits and Hide branches.
• Whenever any commit is selected, the Hide commits button becomes active.
• Whenever any branch is completely selected (ie, all the commits inside it are selected), the Hide branches button becomes active.
• If a user hides a branch, then all commits inside that branch will also be hidden.
• To provide users with a simple way of figuring out how many branches exist and which branches are hidden, as well as to allow them to easily hide/unhide branches, we can also provide an additional option to View all branches list. This option will display all branches, both hidden and unhidden, and users can hide unhidden branches as well as unhide hidden branches from this list. The implementation specifics (whether this option will be a button, where the list will show up) we be determined when designing this.
• Add numbers of hidden and filtered out commits, maybe also shown ones. i.e. Show <number> hidden commits.

Displaying (showing) and unhiding hidden commits and branches:

• Showing and unhiding are two different actions. Showing means temporarily displaying a hidden commit/branch without unhiding it. That is, when the view is refreshed, the hidden commit/branch will be hidden again. This will be useful if the user wants to look at what was in a given branch/commit without necessarily intending to add it back in the view. Unhiding means permanently unhiding the commit/branch. Here, permanently means “until the user explicitly hides it again”.
• We need to provide a way for users to show hidden branches and commits. One possible design is that in the top-right corner (either next to the Delta mode toggle, or below it), provide a toggle/button to Show hidden branches. When this button is active, display this message in small fonts inside the button: Some of your branches are hidden. If this message does not fit inside the button, then display it just above or below the button, or in a tooltip. Another possibility is that at the bottom of the table we provide and information+action items such as `There are hidden branches/commits. Show.". We could also use the space between commit checkboxes somehow to display some indicators. The option that we implement will be determined when designing this feature.
• If a user hides one or more commits inside a branch but the branch itself is not hidden, then, next to the branch name, have a toggle/button saying Show hidden commits. Since this button will only be available for branches that have some hidden commits, we do not need a separate message/tooltip to indicate that some commits are hidden.
• When a hidden branch or commit is shown, display it in slightly different style (maybe lighter color font?) to indicate that this is actually a hidden branch/commit. This style applies to the hidden branch name, all commits inside a hidden branch, and all other hidden commits (hidden commits in unhidden branches).
• Next to the branch name of a hidden branch that is currently shown, have a toggle/button saying Unhide this branch.
• In the pop-up menu for a hidden commit (that opens when the triple-dot menu for that commit is clicked), have a menu item saying Unhide this commit.
• If any commit inside a hidden branch is unhidden, the branch also becomes unhidden.

Collapsing a branch:

• Before the branch name, have an > button to collapse/expand the branch (similar to how @arcticbear had designed here). Collapsing a branch does not hide it. Collapsing/expanding can be done for unhidden branches as well as for hidden branches that are currently shown.

• Some scenarios that need to be handled (as mentioned in this comment):

  • a collapsed branch contains a selected commit: In this case, the checkbox next to the branch name will indicate that some commit(s) inside the branch is/are selected. So, this should not be an issue.
  • a commit is selected but we collapse its branch: Same as above.
  • the branch containing the baseline commit is collapsed: We should probably not allow users to hide the entire branch containing the baseline commit. They can hide non-baseline commits within the branch.
  • the above cases, but "show only selected" is enabled: Same as above - it should be okay.
  • a search or filter is enabled -- do we show results in collapsed branches?: I think we should include results in the collapsed branches, but still leave the branch collapsed. Users can uncollapse the branch and see which commit passed the filter.

How to handle filters:

• When a filter is applied, display all the unhidden branches and commits that match that filter. If there are any hidden branches/commits that match the filter, provide an indication of this to the user and allow a way to show the hidden branches and commits. One possible design is to keep the Show hidden branches button active. Within a branch, if there are hidden commits that match the filter, keep the Show hidden commits button for that branch active. Another possibility is I would try to explore an option with the table. E.g. write at the bottom "There are 5 stale and 10 branches that do not seem relevant. Show." This way, the functionality remains consistent regardless whether or not filters are applied.
• To make it easy for users to hide all old branches/commits (if they are working on old repositories and want to hide all items that are, say, more than 2 months old - as indicated bu @Suor in this comment), we can add a filter by Created date. Then, users would apply this filter. Once they get the results, they would select all the results and hide them. One problem with this can occur if there is a branch that has both old and new commits. In this case, once they apply the Created date filter, they’ll see the old commits in this branch. Now, if they select this branch and hide it, then they will end up unintentionally hiding all the new commits of this branch as well (because hiding a branch hides all commits in that branch). A possible solution to this is that if the filter results contain some, but not all, commits of any given branch, we can display a message next to the branch name saying Some commits in this branch got filtered out. We can also use some warning icon instead, and display the full message in a tooltip on mouse-over on the icon.
• An alternate to how to handle filters is: In the filters pop-up, add a toggle Include hidden commits. If this toggle is selected, include the hidden branches/commits that match the filter criteria in the list of branches/commits that are displayed in the style used for hidden items (lighter color font?). The problem with this alternate is that if the user saves the filter without unhiding the hidden commits/branches, then when the view is refreshed, the hidden items will not be visible anymore, which will be confusing to the user.

[Suor]

Thanks @tapadipti. I would also add numbers of hidden and filtered out commits, maybe also shown ones. I.e. Show <number> hidden commits.

[duijf]

Thanks for writing down this proposal @tapadipti!

Showing and unhiding are two different actions

What's the use-case for having two different actions here? In what cases would a user prefer one over the other?

Remark on terminology: show and unhide are very closely related. Using words that are so closely related could get pretty confusing. Are there different names that we could choose? (Sorry for raising such a bikeshedding issue)

If we want better names, here are a few suggestions:

• Use inspect for 'show me this branch until I refresh the page'
• Use show or display for 'always display this branch on the view page'

[tapadipti]

What's the use-case for having two different actions here? In what cases would a user prefer one over the other?

It's basically what you've summarized in your name suggestions - let me take a quick look vs let me add it back to my experiment table.

Use inspect for 'show me this branch until I refresh the page'

👍

[shcheklein]

Excellent summary, @tapadipti ! Ticket name is a bit misleading now. We need to create a separate Story to address this "hiding redundant / uninformative commits / branches ", wdyt?

---

A few comments thoughts as I read it:

If a commit does not have any changes in metric values compared to the previous commit in the same branch, hide it by default.

probably also no changes in params, data, and source code (at least pipeline dependencies). Same metrics is also a result, right?

If a branch does not have .dvc in the latest commit

we should keep in mind custom metrics/plots/params

Whenever any branch is completely selected

this is a bit complicated (also we don't allow selecting more than some number of commits?) ... add an explicit action to hide a branch?

we can also provide an additional button to View all branches list

we are getting a bit too many buttons .. can we make come up with some UI/UX in the table for example to highlight this?

the branch containing the baseline commit is collapsed:

consider making the whole branch highlighter then as a baseline for visibility. Also what happens if we hide a branch with baseline.

Show hidden branches/commits button

Again, too many button, not very explicit. I would try to explore an option with the table. E.g. write at the bottom "There are 5 stale and 10 branches that do not seem relevant. Show."

Commits - show some sign in between of checkboxes?

Created at filter

GH has a notion of Stale branches- how do they define them? Could we use something similar/same mechanism.

We would need to hide branch names in other places in the table?

[mvshmakov]

@tapadipti great summary!

We should also merge somehow the Show hidden branches and Show hidden commits modals because it will become too inconvenient to toggle one commit and one branch in several actions and may become confusing.

[tapadipti]

@Suor @shcheklein I've updated the above comment to include your suggestions (marked in bold).

We need to create a separate Story to address this "hiding redundant / uninformative commits / branches "

Will do and update the link here.

GH has a notion of Stale branches- how do they define them? Could we use something similar/same mechanism. We would need to hide branch names in other places in the table?

Will take a look.

it will become too inconvenient to toggle one commit and one branch in several actions and may become confusing

@mvshmakov Not sure I understand this. If we hide all commits in a branch when they hide the branch, it shouldn't be inconvenient, right? Or did you mean something else?

[tapadipti]

We recently released changes to auto-hide commits that do not change metrics/files as well as manually collapse and hide commits and branches as needed by the user. @aguschin could you pls check if this addresses the issues you raised.

[aguschin]

Cool, thanks! Took me to force-update the View from the issue description, but now it looks like everything is ok! Thanks for the huge work on this :)