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 list. And what about the tools that are not actively maintainted? For example 'contrib/hg-to-git'. > - 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 whole. 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. -- Felipe Contreras -- 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
