Junio C Hamano wrote:
> John Keeping <j...@keeping.me.uk> writes:
> > And it is now probably too late for that to make Git 2.0,...
> Anything with end-user visible changes in the core part that is not
> a fix to a regression introduced between v1.9.0..master is too late
> for the upcoming release. We are way past -rc1.
The patch in question only affects users of hg v3.0 since it's
surrounded by a 'check_version(3, 0)'. Therefore it cannot introduce
regressions, there's no reason not to apply it.
> >> So I think these are the two options:
> >> 1) Include git-remote-hg/bzr to the core and distribute them by
> >> default (as is the current intention)
> >> 2) Remove git-remote-hg/bzr entirely from the Git tree. And do the
> >> same for other tools: git-p4, git-svn, git-cvs*. Given the huge
> >> amount of people using Subversion, we might want to defer that one
> >> for later, but eventually do it.
> Isn't there a middle ground? The option 1.5 may be like this:
> - Eject tools in contrib/ that would benefit the users better if
> they were outside my tree. There are a few points to consider
> when judging "benefit better if outside":
> * Their release cycle requirements are better met outside my tree
> (the "remote-hg depends not just on Git but Hg internal" issue
> we have discussed).
Shouldn't *I* be the one most qualified to know if the release cycle
requirements are better met outside the git.git tree?
> * They are actively maintained. The overall Git maintainer would
> merely be being a bottleneck than being a helpful editor with
> respect to these tools if we keep them in my tree, and we
> expect that the tool maintainer would do a much better job
> without me.
Perhaps. But only if the patches are reviewed throught the git mailing
And what about the tools that are not actively maintainted? For example
> - Keep tools that are not actively maintained but still used by the
> users widely in my tree, but when their external dependencies
> become baggage to Git as a whole, demote them to contrib/ and
> stop installing them by default.
That implies that git-remote-hg would become a baggage to Git as a
If you are arguing that git-remote-hg should be distributed by default,
and only if the dependencies become a problem, demote to 'contrib/' that
is fine. The same for git-p4 and other tools already out of contrib.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html