Junio C Hamano wrote: > The way I envision the longer term shape of git-remote-hg.py in the > contrib/ is either one of these two: > > (1) manage it just like contrib/hooks/multimail/, keeping a > reasonably fresh and known-to-be-good snapshot, while making it > clear that my tree is not the authoritative copy people should > work off of; > > (2) treat it just like contrib/emacs/vc-git.el, which found a > better home and left my tree at 78513869 (emacs: Remove the no > longer maintained vc-git package., 2009-02-07); or > > The first one may be more preferrable between the two, if only because > distros would need time to adjust where they pick up the source > material to package up, but it still needs cooperation with the > "authoritative upstream" and this project to allow us to at least > learn when the good time to import such good snapshots. I will not do that. If you want my help to improve *your* tree, you have to start by answering the *one* question I've repeatedly asked you to clarify. In fact if you go for this I would consider it an act of sabotage against these new projects. If you hadn't made me waste all this time chasing a non-attainable goal, these projects would already be packaged by distributions, instead of hidden in some corner of /usr/share. Distributions wouldn't even be aware of the move, and it might take bug reports to make them realize that. There will be already enough damage to the reputation of these tools with Git v2.0 shipping them broken. Not aligned at all with your previous statement that you wanted these to "flourisn". In fact, I think you should remove them already from v2.0. Because this doesn't need release candidates. Unless you think user feedback will make you change your mind about not graduating them, moving them in 2.0, or 2.1 will be the same, since you are going to ignore the feedback anyway. This also has the advantage that you won't be shipping them broken in v2.0. At the very least there should be a big fat message warning each time the tools are run, warning the users that they are unmaintained, and the right location for them. And yes, I also think this should be done for v2.0. -- Felipe Contreras -- 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