ovity / octotree

GitHub on steroids
https://www.octotree.io/
GNU Affero General Public License v3.0
22.83k stars 1.78k forks source link

[Feature Request] - View / Search Branches On Repo #1101

Open Sayvai opened 3 years ago

Sayvai commented 3 years ago

Description

Could we have a feature where we can see a list of branches (maybe sorted by most active first) on the side-panel, a dedicated section similar to that of View Pull Requests section?

On top of that, you could implement a fuzzy search facility, which will allow the user to enter the name of the branch, and while the user types the results will be dynamically re-rendered, maybe with a sensible text input debounce rate, surfacing and narrowing the results of branches on the main list within the side-panel.

The list of branches themselves would also be linked, whereby when clicked, the main page will navigate to the commits list of the target branch.

Thoughts? 🤔

danhgit commented 3 years ago

For now, if I want to change branch, I would click the Branch dropdown in the repo code page. I wonder why you need this added to the Octotree sidebar. What are your use cases? What do you think the behavior should be when people change branches outside the code page? Thanks.

Sayvai commented 3 years ago

True, and a fair point. But then i could also argue that the View pull requests feature is very similar in that respect, where I could simply click on the Pull requests tab on any repository page and it will list all open pull requests by default.

Would that also make the Octotree feature View pull request kind of redundant using a similar argument?

Also, with my particular suggestion, it would reduce the number of wasteful page refreshes, whereby performing such actions on the side-panel could reduce that number by a factor of several, as i could already be on lets say a pull request page, and so i'd have to click on Code tab (refresh performed), then click on branch list dropdown and filter down on search, and then click on target branch within dropdown (another refresh performed), and the click on the commits link (another refresh performed).

So now imagine if i could do all this on the side-panel, with only one refresh performed throughout the while process. Wouldn't that be much more of a seamless experience?

Sayvai commented 3 years ago

Also in addition to the original suggestion of this ticket, we could also add a Pinned branches feature to the ticket, where the user would be able to pin (and unpin) target branches from the list, like favourites, whereby the pinned branches would always be sorted at the top of the list with a particular pinned iconography next to each pinned branch within the list (or a simple background highlight).

danhgit commented 3 years ago

Thanks. Couple of questions:

Sayvai commented 3 years ago

Thanks. Couple of questions:

  • Because branches are only relevant for code page (i.e. main repo page), I want to know what the behaviors of branch selection in non-code page. Say you're in a pull request page. Then change the branch on Octotree sidebar. What would the behavior be? It goes back to the code page? What should the active branch be when in non-code page?

I imagined that the branch link would navigate to the page which lists the commits within the target branch.

So for example route to the URI https://github.com/<ORG>/<REPO>/commits/<BRANCH_NAME>

  • Would it suffice to start with a dropdown for the list of branch without any bells & whistles like pin, search etc.? Maybe with a check for the default branch, but nothing else. Or are those necessary for this feature to be useful?

Sure, you can start off at a basic level, and then iterate with the additional features later on (search + pin).

But based on my personal everyday usage of GitHub, i generally check over of there any commits additional commits made to a particular branch, especially that i am involved in, but not actively working on (yet), so i can decide when to rebase (or merge) down that branch with which my other colleagues have committed to into my active working feature branch. If that makes sense.

So for me personally, a search + pin would be really handy.

It may or may not be a common use-case, but it's just my typical GitHub workflow. I'll leave this to your discretion.