Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


Copy link to this message
-
Re: git workflow
On 1/2/13 7:03 PM, Jay Kreps wrote:
> David,
>
> So are there any changes you think we should make to the instructions? I
> think what I wrote matches what you are describing.
I think what you've got in the wiki is great (didn't read it before
sending my message earlier - oops)
> The git patch support does seem better since I think it maintains
> authorship and allows you to transmit multiple commits as a single file (if
> needed).
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.
> -Jay
>
>
> On Wed, Jan 2, 2013 at 2:16 PM, David Arthur <[EMAIL PROTECTED]> wrote:
>
>> Here is what I've been doing
>>
>> * Clone Kafka locally (git clone git://github.com/apache/kafka.**git<http://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"
>>
>> HTH
>> -David
>>
>>
>>
>> On 1/2/13 4:45 PM, Jay Kreps wrote:
>>
>>> 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).
>>>
>>> https://cwiki.apache.org/**confluence/display/KAFKA/Git+**Workflow<https://cwiki.apache.org/confluence/display/KAFKA/Git+Workflow>
>>>
>>> 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.
>>>
>>> Cheers,
>>>
>>> -Jay
>>>
>>>
 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB