From: Junio C Hamano <gitster@pobox•com>
To: John Keeping <john@keeping•me.uk>
Cc: Felipe Contreras <felipe.contreras@gmail•com>, git@vger•kernel.org
Subject: Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Date: Tue, 06 May 2014 10:59:16 -0700 [thread overview]
Message-ID: <xmqqeh06g557.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140505195525.GC23935@serenity.lan> (John Keeping's message of "Mon, 5 May 2014 20:55:25 +0100")
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.
>> 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.
next prev parent reply other threads:[~2014-05-06 17:59 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 22:38 What's cooking in git.git (Apr 2014, #09; Tue, 29) Junio C Hamano
2014-05-05 18:45 ` John Keeping
2014-05-05 19:08 ` Felipe Contreras
2014-05-05 19:55 ` John Keeping
2014-05-05 20:34 ` Felipe Contreras
2014-05-05 21:43 ` Felipe Contreras
2014-05-06 17:59 ` Junio C Hamano [this message]
2014-05-06 18:54 ` Felipe Contreras
2014-05-05 23:50 ` Junio C Hamano
2014-05-06 0:20 ` Felipe Contreras
2014-05-06 0:39 ` Felipe Contreras
2014-05-06 8:07 ` John Keeping
2014-05-06 8:32 ` Felipe Contreras
2014-05-06 19:34 ` Junio C Hamano
2014-05-06 19:39 ` Felipe Contreras
2014-05-07 11:44 ` Greg Troxel
2014-05-07 19:54 ` Felipe Contreras
2014-05-07 23:38 ` Greg Troxel
2014-05-08 0:18 ` Felipe Contreras
2014-05-08 7:29 ` Chris Packham
2014-05-08 7:56 ` Felipe Contreras
2014-05-09 0:40 ` David Lang
2014-05-09 0:58 ` Felipe Contreras
2014-05-09 0:58 ` Submodule improvements (Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)) Jonathan Nieder
2014-05-08 18:31 ` What's cooking in git.git (Apr 2014, #09; Tue, 29) Junio C Hamano
2014-05-07 0:01 ` Junio C Hamano
2014-05-07 0:17 ` Felipe Contreras
2014-05-07 8:05 ` John Keeping
2014-05-07 9:26 ` Felipe Contreras
2014-05-07 18:56 ` Junio C Hamano
2014-05-07 19:28 ` John Keeping
2014-05-07 19:50 ` Felipe Contreras
2014-05-07 20:26 ` Felipe Contreras
2014-05-07 20:44 ` John Keeping
2014-05-07 21:38 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqeh06g557.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=felipe.contreras@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=john@keeping$(echo .)me.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox