I don't know about other people but I find git kind of confusing. I thought it would be useful to try to document the normal workflow for different use cases: 1. Contributing a patch 2. Reviewing and integrating a patch that is contributed 3. Doing development as a committer 4. Keeping a copy of your local work on github (since it doesn't seem Apache has a place to keep local backups of work in progress).
I would like to link this up from the contributor page to help people (including my future self). Objections?
I am not a git expert, so any feedback to improve these recipes or bug fixes (since I haven't tried everything) would be very much appreciated. If you are about to do one of the above things, try the recipe and see if it can be improved.
* Clone Kafka locally (git clone git://github.com/apache/kafka.git) * Create feature branch off of trunk (git branch KAFKA-657) * Do work on the feature branch * Rebase from trunk (git rebase trunk). This minimizes or eliminates any conflicts when people try to apply your patch. * Generate a diff like: git diff HEAD~5 > KAFKA-657v7.diff (this essentially squashes all my commits into one diff)
To apply a patch and test I would (in theory), create a local branch from trunk (e.g., KAFKA-657-integration), apply the patch (git apply KAFKA-657v7.diff), and test the patch.
Another approach would be to use the built-in Git patch stuff (git format-patch and git am). git format-patch will create a patch file per commit, which may or may not be what you want.
Pushing local changes to a fork in GitHub is also pretty simple. You just need to have both GitHub repositories set up as remotes in your local repository. E.g., add your GitHub fork as a separate remote "git remote add mumrah [EMAIL PROTECTED]:mumrah/kafka.git", then push your feature branch to it "git push mumrah KAFKA-675"
On 1/2/13 7:03 PM, Jay Kreps wrote: I think what you've got in the wiki is great (didn't read it before sending my message earlier - oops) The only downside of the patch set vs an single diff is sometimes you don't want people to see all your incremental development. In this case, a developer could squash commits locally before generating the patch set.
Ok, I figured out the problem. The problem was with the patch format so I will take care of that ... the patch is minor enough I will take the code changes and whip up a new patch and let Maxime know (assuming that patch is good) about how to make a Kafka patch moving forward).
I noticed the incubation URL was wrong on the README so I walked through the contributor steps and everything worked just perfectly
the only thing I did notice is that the commit message I put in "as a contributor" was part of the patch and everything so I think we should call out some guidelines for making commit messages, like always put the KAFKA-XYZ in the message so when we review and push everything goes in how we expected if we made the change and committed ourselves.
I just could not let it go, now I am going to-do what I need to for work before my daughter wakes up =8^)
On Sat, Jan 5, 2013 at 1:42 PM, Joe Stein <[EMAIL PROTECTED]> wrote:
ok with some more research today it seems the difference and issues I was having was from the patch being made with
git diff vs git format-patch
with git diff (which is how the patch I was reviewing was made) you apply doing "patch -p1 < patch"
no commits messages are preserved with git diff. I think there are pros and cons to this.
If folks make good commit messages then this is great however I prefer the git diff patch myself from contribs because then I can commit with a message for the JIRA ticket and the reviewer
thoughts on git diff vs git format-patch ?
I updated the wiki to deal with the error i encountered since it already references format-patch I but think we should have some consensus for contributors and how they should proceed and how we should too.
On Sat, Jan 5, 2013 at 2:02 PM, Joe Stein <[EMAIL PROTECTED]> wrote:
Although I haven't contributed much here yet, I did want to ask: why diff/patch and not pull/merge? I know my work on getting the SBT build working with a modern SBT was quite a headache for everyone because the diff format was unable to convey things like "delete this binary file and add this other one".
Derek On Sat, Jan 5, 2013 at 10:35 PM, Joe Stein <[EMAIL PROTECTED]> wrote: *Derek Chen-Becker* *Precog Lead Infrastructure Engineer* [EMAIL PROTECTED] 303-752-1700
It makes it easier for a non-committer to contribute via email, but with publicly available repos (a la GitHub) it's just as easy to merge from a remote (and doesn't require contorting through hoops for certain scenarios). On Jan 7, 2013 7:45 AM, "David Arthur" <[EMAIL PROTECTED]> wrote:
The reason we take diffs is because traditionally the mandatory Apache toolchain is svn+jira+patch/diff. When we were on github of course we used that.
I'm actually not sure of the Apache rules here. Can we just directly accept github pull requests? I.e. you fork the apache mirror and send a pull request? Github has lots of tools for seeing diffs, commenting on code, etc so this would be fantastic. Is that considered bad form? We could just have the JIRA point to the github url...
-Jay On Mon, Jan 7, 2013 at 7:05 AM, Derek Chen-Becker <[EMAIL PROTECTED]> wrote:
You even have a pull request (5 months old) already. Things like pull request review/commenting, as mentioned, are very nice, and it would be a shame to not be able to use them.
Derek On Mon, Jan 7, 2013 at 9:06 AM, Jay Kreps <[EMAIL PROTECTED]> wrote: *Derek Chen-Becker* *Precog Lead Infrastructure Engineer* [EMAIL PROTECTED] 303-752-1700
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext