Re: What's not in 'master', and likely not to be in, until 1.5.4

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 21, 2008, 05:35 UTC
Message-ID: <alpine.LNX.1.00.0801210009290.13593@iabervon.org>
In-Reply-To: <7vr6gb3nv1.fsf@gitster.siamese.dyndns.org>

On Sun, 20 Jan 2008, Junio C Hamano wrote:

Show 14 quoted lines

> Here is an update to the list I sent earlier.
> 
> Topics that I thought may deserve attention, discussion and
> eventual inclusion but are not 1.5.4 material.
> 
> I think these two could be part of 1.5.4, but I left them out of
> 1.5.4-rc4 (IOW, I do not think they should be on this list):
> 
>  * marking output from "diff --{no,src,dst}-prefix" as a non-git
>    diff (me)
> 
>    Linus had an objection but I think I made a reasonable
>    argument against that.  Haven't heard back since then, so
>    this is in limbo.

If Linus is still not happy with it, we could instead require that the prefixes have at least one slash, not at the beginning, and figure that 'a/foo/' 'b/foo/' intends the effect it will have on git-apply. The effect of --no-prefix on git-apply is kind of incoherent, so that's more sensible to prohibit.

> I suspect it might be a good idea to make an early declaration
> that 1.5.5 is to resolve the above listed issues plus the ones
> already in 'pu' (and nothing else), and have a fairly short
> cycle after 1.5.4.

I've got 4 topics that I've been holding back until 1.5.4 is out:

 * Use fewer connections to perform git-native fetches (this is actually 
   from before transport.c made it to master, and I forgot about it until 
   I was rebasing stuff and it didn't go away).

 * Make checkout a builtin (includes a certain amount of infrastructure 
   improvement for programs that might wants to read multiple trees into 
   the same index in memory in sequence)

 * Generate a cover letter from format-patch (originally Dscho's patch; I 
   reworked a bunch of it)

 * Let the user provide aliases for URL patterns (should be useful for 
   groups whose members don't all have the same best access to a remote
   repository)

If you want to have cycles that only handle stuff that's been submitted beforehand, it doesn't make sense to have a feature freeze beforehand, and therefore only take patches in that cycle from people who ignore your wishes. I think in order to do that sort of thing, we'd need a tree run like -mm, maintained by somebody whose attention won't be taken away from the mainline release process by managing patches that are cooking.

	-Daniel
*This .sig left intentionally blank*