This can be used for hiding merged branches in branch manger,
like Github does.
(setq magit-branch-manager-options '("--no-merged"))
Looks good. Two comments:
Do not mention Github in the comment.
I fixed the docstring. I am not sure about changing it to magit-branch-manager-option. You can set several options for git branch, like this:
(setq magit-branch-manager-options '("--no-merged" "master" "--abbrev=10"))
It is also constant with other variable such as magit-git-standard-options.
Yes, it seems that currently --no-merged is the only useful option. But there can be more useful options in the future.
Ah, you mean to drop "manager-" part. I'll do it.
Exactly. It serves in the manager but there is nothing "manager" about it, it is straight up git branch
Rename to magit-branch-options
Thinking about this, it probably makes sense to add "manager-" to the variable, as it is not used for other branch operations such as creating and deleting.
I have mixed feelings about this one. It seems to me that the set of options that would make sense (while not breaking the display ?) is probably fairly limited. Also, I'd think that filtering branches (like unmerged ones) would be more useful if was accessible dynamically. Shouldn't we try to extend the current branch manager menu with options ?
Right, I agree that setting options dynamically is better. I will make a pull request later.
But it is better if I can set default option and toggle it dynamically. Is it possible to do that by magit UI in general (e.g., add "-a" option to log view by default)?
well, the way it's done currently (which is less than ideal in my opinion), is to store those dynamic options temporarily in magit-custom-options. See magit-key-mode.el for details.
hmm, interestingly I didn't know about that mag-menu project. I guess I'll put in my todo-list to investigate whether we can just drop entirely that code from magit, and rely on that external package instead !
I have been considering making magit more modular lately. This would be an interesting approach in that direction. I also had in mind to separate the git interface in a way that could be used by other emacs utilities. And also separate the GUI part to increase consistency and code reuse.
yep, at this point more modularity would be highly desirable.
Pinging @chumpage about this discussion (in case you did not notice).
I really like the idea magit using mag-menu so that everyone can contribute to and get benefit from this great interface.
I would like to suggest merging these efforts under the magit organization.
I think the way https://github.com/yesodweb does it is really nice.
They have a main product, yesod, but they also have libraries.
The libraries came from developing yesod but now have a life on their own and are packaged independently.
They are all merged together with git submodules for the main product.
I'd be happy to bring the improvements I made in mag-menu back to a new version of magit-key-mode that's easily usable as a stand-alone library but still under the magit org. The approach dudebout describes with yesod would work, although I'm not sure separate repos are really necessary. At least with melpa you can have multiple packages in the same repo.
Obviously I'd also be fine if you wanted to have magit use mag-menu as a package dependency.
yes I think it would be best to have magit depend on mag-menu directly, so that we can centralize efforts there (see for example recent fix in #514 which I personally dislike :( ). There's no reason why that particular piece of code should be tied to magit in the first place.
If you'd like to do that, I'd gladly accept a patch :)