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

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

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*