On Wed, Feb 15, 2012 at 10:07:16PM -0600, David A. Greene wrote: > I've attached Avery's response below. The short summary is that he > thinks maintaining it in the vger git repository is the way to go and > that he's fine moving patches to/from GitHub as necessary. > > [From Avery:] >> I'm sure the potential benefit of putting git-subtree in the contrib/ >> directory is that we could then use git-subtree to maintain the >> git-subtree git subtree, which is a fun wordplay, but perhaps >> ironically, as a single rarely-changing file, git-subtree is probably >> not the right tool for these purposes :) I'm not a git-subtree user, nor am I the maintainer who would pull from you. So I am somewhat on the sidelines of this particular discussion. Usually we would incubate new and radically different commands in contrib, and then if they prove to be good, make first-class commands of them (e.g., git-new-workdir has been in contrib for a while, and as it has proven itself to many people, there is talk of including it as a core command). My impression is that git-subtree has already done this incubation and proving step in its own repository (but like I said, I do not use it myself, so that is just going on list hearsay). So it seems like the logical step would be to graduate into the main git repository. And I gather from Avery's response that he agrees. Of course there's no real reason we can't take it slow by putting it in contrib, and then graduating from there. It just seems like an unnecessary and complicated interim step. Either way, I do think it's worth saving the commit history by doing a real merge. I dunno. It is really up to Junio, I guess. He usually relies on list consensus for decisions like this, and there has not been that much discussion. What do users of git-subtree think, as this would primarily benefit them? And what do other members of the git@vger community who do not use git-subtree think of the burden of carrying it as a first-class command (not so much the burden of adding it, but of maintaining it, fielding reports when it is broken, etc)? As a non-user, I am totally fine with it. I think the burden is not that high, and you have already promised to deal with ongoing maintenance issues. -Peff -- 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