Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka >> mail # dev >> git workflow

Copy link to this message
Re: git workflow
Diff/patch makes it easy for non-committer to contribute.

On 1/7/13 12:52 AM, Derek Chen-Becker 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:
>> 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:
>>> 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:
>>>> that did not work either
>>>> I can't even get the patch to apply from the latest trunk because of
>> this
>>>> message of patch without email
>>>> so the patch is here
>> https://issues.apache.org/jira/secure/attachment/12563266/KAFKA-133.patch
>>>> I go through the steps on the git workflow
>>>> git clone https://git-wip-us.apache.org/repos/asf/kafka.git kafka
>>>> cd kafka
>>>> git fetch
>>>> git checkout trunk
>>>> //already on trunk
>>>> git apply --stat ../KAFKA-133.patch
>>>> //project/build.properties         |    2 +-
>>>> //project/build/KafkaProject.scala |   44
>>>> +++++++++++++++++++++-----------------
>>>> //2 files changed, 25 insertions(+), 21 deletions(-)
>>>> git apply --check ../KAFKA-133.patch
>>>> git am --signoff < ../KAFKA-133.patch
>>>> //Patch does not have a valid e-mail address.
>>>> my git --version =
>>>> now what is interesting is when I grab the patch using wget
>> https://issues.apache.org/jira/secure/attachment/12563266/KAFKA-133.patchinsteadof downloading it it through a browser I get "Patch format
>>>> detection failed." instead of the error saying "Patch does not have a
>> valid
>>>> e-mail address"
>>>> I am guessing it is something I am doing wrong and could be doing
>>>> different but am interested to see where exactly the problem is.
>>>> any thoughts?  I gotta work on some code for work right will bang on
>> this
>>>> later tonight again but if anyone can reproduce this same thing or not
>> or
>>>> has an idea that would be great.