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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 6, 2014, 18:54 UTC
Message-ID: <53692ff63ae2f_2855e9b3089e@nysa.notmuch>
In-Reply-To: <xmqqeh06g557.fsf@gitster.dls.corp.google.com>

Junio C Hamano wrote:

Show 7 quoted lines

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

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.

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

Shouldn't *I* be the one most qualified to know if the release cycle requirements are better met outside the git.git tree?

Show 5 quoted lines

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