0.15.1869: Can no longer delete local copies of remote branches

[beporter]

In the previous release (0.14.95), you could delete the local copy of a remote branch (blue tags in the UI) by right-clicking and choosing delete. This option is now grayed out in 0.15.1869. Is there a reason this is no longer available? In this screenshot, why can I no longer delete origin/f/sample-vmware-config?

[rowanj]

This was actually put in as a usability change, since it's not obvious to a user unfamiliar with git that the action will be un-done in most cases by the next fetch of the remote (since the deletion of the remotes/remotename/name ref isn't pushed to the server).

I was hoping this will be fixed soon by the addition of a 'prune' option when fetching from a remote; and an explicit 'delete branch from remote' action from the sidebar; or do you have a workflow that wouldn't be solved by that?

[beporter]

Although I've been working on a git extension script to solve this, my [crazy] workflow involves private repos. I check out tracking branches to rebase and force push locally (via GitX plus cmdline for the force push), then merge the associated PRs using GitHub's web interface, and "clean up" the leftover local copies of the branch (that GitHub just deleted from its end following the PR merge) in GitX again. Prune would probably work too, but in the meantime, my workflow now involves not only GitX and GitHub.com (which admittedly is annoying enough) but also the command line--twice.

My workaround has been to stick with 0.14 for now. I don't have any performance issues with the underlying git engine against my repos in 0.14, so I can stay on it indefinitely and wait for a forthcoming improvement in GitX to resolve my workflow issue via prune or otherwise. (Maybe by that time I'll have my "rebase, merge and close this PR" script complete and this will be moot!)

Thanks for the attention.

[beporter]

I would also like to humbly add that I disagree with trying to protect users from git's power/danger. Git itself is a complicated tool. That's okay. That's what makes it good.

I don't use GitX to hide that complexity, I use GitX to better leverage it. As a git "expert"(-ish) I don't want my toolchain to cripple my ability, I want it to enhance it.

I personally think it should be left to other projects to cater specifically to "beginners" (which admittedly is easy for me to say since I'm not one anymore.)

[rowanj]

I agree that the full power of git should be exposed in the UI, I just think that deleting a remotes/* ref in that manner is not what people are looking for. Just like dragging around the HEAD ref, it's going to be inviting surprising behaviour.

Anyway, I'll at least look at re-enabling the old behaviour; since it's still premature to remove it before those other behaviours are in place.

[beporter]

I understand, but it's definitely what I was looking for.

That said, I certainly wouldn't want to be the one getting the support requests asking, "Why did GitX do this?" when the answer is always, "because that's what git would do," but I still think that just because a behavior is non-obvious doesn't mean it should be disabled. After all, half of git itself wouldn't work if it followed that same rule! I think part of the appeal of a GUI is that it can enable interaction methods that are cumbersome or impossible on the command line.

I'll be quiet and let you work. 😶 Thanks!