I’m starting to run into this problem where there’s a loooot of branches and because they’re not deleted, they kinda just sit there in the UI.
In the branch view, I don’t see any way to hide branches that have been merged. This means that when I make a branch, get it PRd, then merged into main, it’s still just sitting there.
In the code reviews tab, there’s the same problem where you can’t hide or filter out PRs that have already been merged. Moreover, if your title is too long, the little “merged” marker is gone too.
This PR is Reviewed and Merged but it doesn’t show the “merged” marker.
There’s no “Merged” status to filter by:
I mean something like this isn’t strictly blocking anything, but it just seems like a crucial QoL feature that I’m shocked isn’t supported.
Plastic claims to support and work well with tens of thousands of branches in the docs that I’ve read, and the recommended workflow is to make task branches. When people ask, “why can’t I delete branches?” the response is “Plastic does it differently and you don’t need to do that”, but then I see something like this and it just makes me do a double take. Like, am I just missing something?? but I can’t find it in the UI for the life of me.
The amount of little paper cuts that we’re running into is seriously concerning
We truly value your input and want to ensure it gets the attention it deserves. To help us with this, would you mind using the link below to submit your feature request directly to our product team (Please mention this thread)? They are dedicated to tracking and considering each suggestion for future updates.
If there’s some way for us to see feature requests on a roadmap or something, that would be reassuring to us, rather than the request going into a void.
I don’t see how to submit several ideas, it seems I can only submit one thing and pick one level of importance, and then whenever I hit submit again it just adds more comments?
I’m afraid that this is the only public roadmap available for customers. We are receiving multiple feature requests a week that need to be triaged and eventually, some of them will be added to the roadmap.
Let me check with the product team how to do it. For now, if there is no other alternative, you can include all your feedback in a single report.
Can you explain the details? Plastic is not allowed to use a branch name if it already exists. A branch could be hidden but it could be unhidden at some point. Why would you need to re-use a legacy branch name? What is the approach you are following to name your new branches?
Exactly. Because of this, the namespace gets used up, unlike git, where you would delete branches after merging them, getting the name back.
We try to have as few active branches as possible, while still working with feature/fix branches.
So a branch could be named, let’s say “Menu Update”, “Highscore Fix”, “Enemy Pathfinding”, etc.
When someone uses such a name, it is possible, and on longer projects likely, that the name has been used before.
It is not practical and does not seem like good practise to reuse a branch from months or years ago, just to reuse the name. They are not the same, a new branch is required to make the structure clear.
I think there must be a better way than to just add increasing numbers to the new name, which feels like a clunky solution to a technical limitation.
I would recommend you reconsider how you are naming the branches. A good approach (and the one we are internally following) is using the task-per-branch methodology so each branch is linked to a task ID. In the branch comment, you can include some information of the task: “Menu Update”, “Highscore Fix”, “Enemy Pathfinding”, etc
Once a task is integrated (or discarded), we shouldn’t use the same branch name again in the future.
That’s certainly a way to work around it, and I suppose we’ll adapt it out of necessity. But it’s annoying for merging, and other situations where you have to use a list of branches since you need to know by heart what the id is you’re looking for.
So I guess it’ll be ID + a name for the time being.
It looks like the documentation is outdated - it’s no longer possible to get a field ID the way it was explained in Jira.
It also looks like quite a hassle to set up for each Plastic installation individually. With this kind of thing, you really want a per-repository config file so you only have to solve the problem once; not once per workstation.
Anyway. We’ll adopt the ID naming, even without the integration it does solve some problems.
