Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email
Hi, Michael Haggerty wrote: This series consists of a single patch that adds a directory contrib/hooks/git-multimail/ containing five files, described in the patch's commit message. Yay! I look forward to seeing it. [...] The first of these commits consists of a code drop from the private repository just mentioned. The recent part of this history includes commits by other authors. That could be a reason to do a subtree merge if you want. A code drop with a commit message that acknowledges the contributors would also presumably be fine. [...] * How to organize future development? Directly in the Git repo, using the git mailing list, etc? As a fork of the Git project that occasionally issues patches and/or pull requests to the main project? Or as a separate project that does not include the whole Git tree, which is occasionally merged back to the Git project using subtree merge? My personal preference is that patches come on the git list, are reviewed here, and then go to your fork of the Git project that Junio can periodically pull from at your request (like git-svn). But of course this is up to you, too. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email
Jonathan Nieder jrnie...@gmail.com writes: My personal preference is that patches come on the git list, are reviewed here, and then go to your fork of the Git project that Junio can periodically pull from at your request (like git-svn). But of course this is up to you, too. And also me ;-) Yes, I very much prefer the way how git-svn is managed. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email
On 04/21/2013 08:44 PM, Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: My personal preference is that patches come on the git list, are reviewed here, and then go to your fork of the Git project that Junio can periodically pull from at your request (like git-svn). But of course this is up to you, too. And also me ;-) Yes, I very much prefer the way how git-svn is managed. Let me see if I understand what that means: * I maintain my own Git clone * Patches to git-multimail would go to the Git mailing list like patches to other patches to the Git project, but I would be the one to git-am them, monitor discussion, help with review, etc. I would presumably apply the patches near your master (or near maint when necessary). * When I think a batch of patches is ready, I merge them to my master and publish my master somewhere. (Or is it better I publish the feature branch and leave it to you to merge directly to your master?) Then I send a merge request to you and the Git mailing list with the URL and SHA-1 of the branch that I would like you to merge. That seems very workable. What is your preference regarding the history to date? Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email
Michael Haggerty mhag...@alum.mit.edu writes: That seems very workable. That is pretty much it. What is your preference regarding the history to date? The only thing I deeply care about is that initial and subsequent git pull I'll do from you [*1*] will pull in commits that touch only the multimail part in the contrib/ area and not mixed with unrelated changes to other areas. If the history you have so far would later help others learn the motivation, design, constraints etc. while developing it, which cannot be easily read from the resulting code, i.e. help maintaining it in general, it's a good idea to keep it. In such a case, however, people may want to review that history as well. If it is the oops, it didn't work, let's try another kind of record as we build type of history that may not help the future maintainace that much, you may instead want to start with a single code-dump here is the first public version (which is reviewed in this thread, I think) without the history behind it. Your choice, in other words ;-) [Footnote] *1* This does not even have to be a stable URL I would place in remote.multimail.url configuration; it does not even have to be a non-rewinding tree. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email
Michael Haggerty mhag...@alum.mit.edu writes: * When I think a batch of patches is ready, I merge them to my master and publish my master somewhere. (Or is it better I publish the feature branch and leave it to you to merge directly to your master?) I think I missed this part, but in the case of git-svn, what we do is the former. The branch Eric makes me pull may be called 'master' in his repository, but it does not contain anything unrelated to git-svn, so from _my_ viewpoint, it is a single topic to improve git-svn. But from Eric's point of view, it is an aggregation of different topics from many people on top of my tree, and each topic may tackle its own theme. I think most of the pulls from him so far were single strand of pearls without merges, but if two or more long topics were cooking in his tree, it would have been perfectly reasonable for him to resolve such inter-topic conflicts before telling me to pull the result. After all, that is what the sub-maintainer of an area is. One who knows the area the best coordinates possibly conflicting changes brought in different topics to the area. Ths same can go for multimail, or any contrib/ material for that matter. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
