Re: git-gui ignores core.hooksPath

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 11, 2018, 00:44 UTC
Message-ID: <xmqqy3huzi58.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <87muyabpuz.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Isn't everyone involved much better solved if we come up with some plan
> to split these off from git.git? I.e. I think if if git-gui, gitk and
> gitweb were proposed for inclusion in-tree today I don't think we'd
> bite, and instead point to things like [1] or [2].

It is actually the other way around. gitk and git-gui had active maintainers and they (not Linus nor I) wanted to have their own release schedule and versioning; they started as eparate projects.

The arrangement was pleasant to work with while the subsystem was actively managed. People can send patches to it just like to other parts of the system (and the change rarely if ever needs to touch both core and GUI at the same time---otherwise it would be impractical to split them out as a separate projects), reviewers would give comments on the list, and subsystem maintainers would pick them up just like I pick up patches to the core part. Then from time to time, subsystem maintainers would give me a pull request to complete the cycle. I do "pull -Xsubtree=git-gui/".

It breaks down when subsystem maintainers go quiet. Even if I were to play a patch monkey backed by volunteer reviewers, I'd still have to pretend that these are separate projects that are occasionally subtree merged, with my own pull requests to subsystem repositories that may never be responded, just in case the separate subsystem projects will become active again.

If you split git-gui off, it would just die, unless somebody steps up and takes it over. And if somebody steps up and takes it over, we can keep merging from their repositories without any problem.