Now the 1.7.4 release is out, I'd like people to help thinking about the next cycle(s). As a discussion-starter, here are my random wishes. Even though this does not attempt to be exhaustive, keeping the number of goals manageably small may help us focus. * The i18n effort Ãvar ArnfjÃrà Bjarmason started two cycles ago has stalled. If enough people feel i18n's Porcelain UI is worth having, I think we would need a brief calming period in the entire tree in order for us to get the minimum support (definition of _() macro that is empty is a good start) and _() mark-up of existing strings in, and then ask everybody to rebase their ongoing work on top of it. * There was a discussion on documentation updates to reduce "here we tell you only the basics; see elsewhere for details", and consolidating the description of configuration options in one place. * Nguyán has been scratching my longstanding itch by attempting to unify two pathspec semantics (the ones based on tree-diff matches only leading path while others know globs) to reduce inconsistencies. I would really want to see this polished and in the main release. * Elijah's fix to "rev-list --objects", together with the updated pathspec semantics will allow us to cleanly implement narrow cloning (possibly deprecating and replacing the narrow checkout in the future). I am hoping that we can lay groundwork on this inside one cycle and the initial end-to-end implementation in another. * Shawn Pearce says that the diff implementation JGit uses (histogram diff) performs way better than the xdiff implementation we use by default. It would be great if somebody can spend time taking a look at it and possibly port it back to C-git. Over the time we have discussed minor glitches and inconsistencies that we all (or at least most of us anyway) agreed we would have done differently if we were writing Git from scratch, yet we cannot retroactively introduce differences not to harm existing users. We may also want to revisit these discussions during this round--if there are reasonable number of them that we can agree the benefit of tweaked semantics/behaviour outweighs the risk of breaking and having to update ancient scripts that exploited obscure corner case behaviour of Git, we would want warn the users loudly, bite the bullet and break them so that we can move forward. We would however need to roll such potentially disruptive changes into a big single cycle, like we did in 1.6.0. I'll follow-up this message with a couple of example proposals. Please send your own, imitating the format of the message, as a reply to this message. Do not forget to retitle your message when you do so (iow, I don't want to see "Re: Planning for 1.7.5 and 1.8.0"). Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html