Hi Jonas! answers inside LieGrue, strub --- On Mon, 9/28/09, Jonas Fonseca <jonas.fonseca@xxxxxxxxx> wrote: > From: Jonas Fonseca <jonas.fonseca@xxxxxxxxx> > Subject: Re: [JGIT PATCH 1/9] mavenizing step 1: moved over the initial poms from Jasons branch Signed-off-by: Mark Struberg <struberg@xxxxxxxx> > To: "Mark Struberg" <struberg@xxxxxxxx> > Cc: "Robin Rosenberg" <robin.rosenberg.lists@xxxxxxxxxx>, git@xxxxxxxxxxxxxxx, spearce@xxxxxxxxxxx, "Jason van Zyl" <jvanzyl@xxxxxxxxxxxx> > Date: Monday, September 28, 2009, 2:46 PM > On Sat, Sep 26, 2009 at 15:50, Mark > Struberg <struberg@xxxxxxxx> > wrote: > > Hi Robin! > > > > a) Actually git-format-patch only created 0001-0009 so > there is no 0/9. > > For larger patch series, it is good practice (at least on > git@vger) to > provide a "cover letter" (see git-format-patch > --cover-letter) to give > reviewers of the patch series an idea of what code is > touched and for > you to give additional information, such as the state of > the patch > series. txs 4 pointing this out. > > > b) 2/9 is the actual directory structure moving. I > received it, but since it is pretty large (330k already with > -M -l0) it might got filtered out? > > If so then may I ask you to please fetch it from http://github.com/sonatype/JGit branch 'mavenize'? It > has the same content I sent to the list. > > Some general notes on the patch series. First, I am glad > you posted it > to have something to discuss and as I have stated in a > private mail I > am glad you are doing this. However, I also think it needs > a lot more > polish before being integrated. > > While I understand that you want to credit Jason for doing > the initial > probe into fully mavenizing JGit, I now think it is wrong > to base the > patch series on his patch. My first impression is that it > actually > removes features (by not keeping the JGit specific > settings), which > you then try to amend later in the patch series. I'm not sure what JGit specific settings you speak about? > In terms of making the patch series more manageable for > you, I think > the best approach is to start with the patches not relevant > to the > mavenizing (renaming PathSuffixTestCase). In fact the fix of the PathSuffixTestCase came a few days later after I found the reason why I miss a few tests. This should be fixed in the current master anyway and has not so much todo with the mavenization itself. > After this comespatches > which only touch pom.xml files. For example, move > jgit-maven/jgit/pom.xml to the top-level pom.xml, extract > relevant > pieces to org.spearce.jgit/pom.xml and > org.spearce.jgit.test/pom.xml, > improving the pom.xml`s by adding checkstyle/<scm> > integration, and > mavenizing org.spearce.jgit.pgm/. The final and most > invasive parts > (renaming/(re)moving code/eclipse files etc) should come > last! I had the following in mind: every single commit should be compileable and working. So it's not easily manageable to move the directory structure in one patch and apply all the changes into the poms in another commit. We could for sure squash the later few commits, but I didn't liked to rebase and push since there have been a few forks of the mavenize branch and I hoped I could pull back a few commits from others and later do a rebase -i. > Taking this approach Robin and Spearce can start > integrating initial > patces and we can all start testing the "mavenization" > sooner rather > than after deciding how to rename things and whether or not > to remove > certain files. > > The above is a proposal and if you and other agree that it > is the > right approach _and_ you do not feel you have the time > necessary to > realize it, I am willing to work on it. Any help is always welcome :) -- 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