Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)

From: Junio C Hamano <gitster@pobox.com>
Date: May 6, 2014, 17:59 UTC
Message-ID: <xmqqeh06g557.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140505195525.GC23935@serenity.lan>

John Keeping <john@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.

Show 9 quoted lines

>> 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).

   * 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.

 - 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.

 - I would not mind having install.contrib-frotz target in the
   top-level Makefile for each of the remaining contrib/frotz
   hierarchies for those users and distro packagers who know their
   platform meets the dependency requirements.

> I'm not sure it needs to
> wait for a major Git release since most of the impact is on package
> maintainers and not end users.

Removal of features is a big deal, I would think, though.