From: Andrey Volkov <avolkov@varma-el•com>
To: Grant Likely <grant.likely@secretlab•ca>
Cc: "David H. Lynch Jr." <dhlii@dlasys•net>,
linuxppc-embedded <linuxppc-embedded@ozlabs•org>
Subject: Re: General GIT MO question
Date: Wed, 18 Jan 2006 15:28:37 +0300 [thread overview]
Message-ID: <43CE3475.9040406@varma-el.com> (raw)
In-Reply-To: <43CD2003.3020903@secretlab.ca>
Grant Likely wrote:
> 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 <first-commit-sha1>
> $ git cherry-pick -r <second-commit-sha1>
> $ git cherry-pick -r <third-commit-sha1>
>
> 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 <messy-commit-sha1>
> $ <edit stuff>
> $ cg commit -c <messy-commit-sha1> # Use the original change message
>
> 3c. Cherry picking works for merging patches too
> $ git cherry-pick -r -n <partial-patch1>
> $ git cherry-pick -r -n <partial-patch2>
> $ git cherry-pick -r -n <partial-patch3>
> $ cg commit
>
> 4. generate patch files for submission to the mailing list
> $ git-format-patch -o <output dir> 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 ?
>
>
Or use stg (http://www.procode.org/stgit/),
steps 1-2 you could made by
stg new
steps 3 trough 5 by :
stg refresh/stg export
--
Regards
Andrey Volkov
next prev parent reply other threads:[~2006-01-18 12:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <43CB3127.7060107@dlasys.net>
2006-01-17 16:49 ` General GIT MO question Grant Likely
2006-01-18 12:28 ` Andrey Volkov [this message]
2006-01-18 19:41 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43CE3475.9040406@varma-el.com \
--to=avolkov@varma-el$(echo .)com \
--cc=dhlii@dlasys$(echo .)net \
--cc=grant.likely@secretlab$(echo .)ca \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox