Re: BuGit

[Stefan Monnier]

>> https://gitlab.com/monnier/bugit
>> It's still primitive (only the command-line UI and the email
>> notification system are more or less complete: the web UI is still
>> read-only, and there is no email UI at all).
> Looks like an interesting experiment.
> These lines look a bit contradictory to me:
>> ...the user can also share the same repository with the main project.
>> Every issue lives in its own branch named bugit/<id>.
> I imagine it might be uncomfortable working on a project which contains
> thousands of branches. You do a pull--and Git shows you all the remotes that
> have changed.  With lots of branches, that would be a lot of output, even if
> you don't check them out locally.

Indeed.  I don't have much experience with such a situation yet, but
I expect "branch-namespace-pollution" to be a problem.

Currently, for BuGit itself, I have 2 central repositories (one for the
code, one for the bug database), but I clone them into a shared local
repository.  So when I do "git pull/push" I access the source repository
(and corresponding branches), and when I do "bugit sync" I access from
the bug repository (and corresponding branches).

That takes care of the use-case you mention, but it still leaves another
problem "git branch -a" includes all the bugit branches, which
is inconvenient.  I haven't tried to solve this issue yet, but I'm
thinking of not sharing the local repository, and instead store the
local bugit repository in a subdirectory like .git/bugit.

> Not sure if there's an option to ignore only certain branches, for
> certain commands.

I use Git's support for multiple remote repositories for that.


        Stefan