From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound-mail-39.bluehost.com (outbound-mail-39.bluehost.com [70.98.111.193]) by ozlabs.org (Postfix) with SMTP id 09DE868916 for ; Wed, 18 Jan 2006 03:49:17 +1100 (EST) Message-ID: <43CD2003.3020903@secretlab.ca> Date: Tue, 17 Jan 2006 09:49:07 -0700 From: Grant Likely MIME-Version: 1.0 To: "David H. Lynch Jr." Subject: Re: General GIT MO question References: <43CB3127.7060107@dlasys.net> In-Reply-To: <43CB3127.7060107@dlasys.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-embedded List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , David H. Lynch Jr. wrote: > I appreciate you feedback on the E12/UartLite stuff I posted earlier. no problem > > I have gotten sufficiently compitent with git that I can use it as a > source code manager. > But despite perusing through a fairly significant amount of git docs, I > have not really grasped how to get from how I work to what seems to be > the norm for patch subimissions. Heh, your tracking the same path of pain that I went through 2 months ago. :) > > Fixing a bug or adding a small feature is one thing. You have a base, > and and end result and a simple diff. But I am porting to a whole new > board, adding support for two new serial drivers, and adding boot to > init serial IO support - all at once, as well as dealing with bugs and > mis-steps along the way. > > I can figure out how to get git to do alot of nice things, but I can > not figure out how to get it to produce a nice modularized set of > patches that includes only those things relevant for kernel submission. Here's what I do, assuming that my changes are in the 'master' branch, and 'master' is based off of 'origin'. BTW, I also use the cogito with git. 1. create a new branch 'cleanup' off of origin so it doesn't have any of my patches in it. $ git branch cleanup origin $ git checkout origin 2. get a list of all my patches; I use 'cg log' and look for the sha1 'commit' tags. $ cg log master p 3a. start 'cherry-picking' my patches one-by-one from 'master' to 'cleanup'. Feel free to use this to reorder patches $ git cherry-pick -r $ git cherry-pick -r $ git cherry-pick -r 3b. If I want to modify the patch before committing; I use the -n flag to only apply the changes; clean up the change, then commit it with the -c flag. Also do this if a patch conflicts. $ git cherry-pick -r -n $ $ cg commit -c # Use the original change message 3c. Cherry picking works for merging patches too $ git cherry-pick -r -n $ git cherry-pick -r -n $ git cherry-pick -r -n $ cg commit 4. generate patch files for submission to the mailing list $ git-format-patch -o origin cleanup 5. (optional) make 'cleanup' the new 'master $ git branch -f master cleanup $ git checkout master > > I am looking for a clue here. How do you produce a clean set of > granular patches including only what you want and not the all the steps > and mis-steps along the way ? -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 663-0761