RFC: My git patch workflow (for wiki)

Jason Guiditta jguiditt at redhat.com
Wed Apr 11 19:55:49 UTC 2012


On 11/04/12 10:40 -0400, Scott Seago wrote:
>On 04/10/2012 03:19 PM, Matt Wagner wrote:
>>Hi all,
>>
>>We have a wiki page or two talking about using git, but one is fairly
>>out of date (it, for example, warns that you shouldn't ever push to
>>master). Another one was written by me some time ago, and needs some
>>changing.
>>
>>What I'd really like is to write up some super-clear documentation
>>allowing those new to the project and/or git to get up to speed pretty
>>quickly. I'd like to send some draft content here, based on my workflow.
>>But I was hoping for feedback on it, both in terms of technical
>>suggestions and advice on wording/ordering/etc.
>>
>>For setup, I'd like to recycle some of the content from
>>https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Git_Workflow
>>(but without the erratic indentation that exists today).
>>
>>For normal workflow, I think something like the following:
>>
>>1.) Update master, with "git pull master".
>>
>>2.) Check out a local topic branch for your work, with "git checkout -b
>>my_new_feature"
>>
>>3.) Do your work, commit your changes to your branch. (Maybe a section
>>on "git add", "git commit" practices, etc.)
>>
>>4.) With your changes committed on your branch, rebase against master to
>>pull in any updates since you started -- "git rebase master" (I normally
>>run "git checkout master; git pull" first)
>
Instead, you can save some effort with:
$ git rebase origin/master

>>5.) Format your patches, with "git format-patch HEAD..master" (or the
>>500 different ways you can express something equivalent). Send them to
>>the list with git send-email.
>>
>I usually use 'git format-patch -C master'
I do this a bit differently as well.  Once I am ready to send my patch
(let's say it is a single one for now), I do:
$ git send-email HEAD~1

>>6.) Do other work on other branches, perhaps, until you receive an ACK.
>>
>>7.) Switch back to your branch (if needed), and rebase against master
>>again.
>>
>>8.) Switch to master, and run "git merge my_new_feature" to merge in
>>your changes.
>>
>I've always run 'git pull . my_new_feature' here.
>
There are a number of ways to do this, but the net should be, imo,
that there is no merge commit, and your commit from the branch simply
ends up on master, exactly as it was on your branch.

>>9.) Push with "git push"
>>
>>I'd also like to have a section on *applying* patches from the list, but
>>I'm not sure how other people do this. I create a topic branch from
>>master, and then use mutt to pipe the message body to "git am -s". How
>>do other people handle this?

I do git am <patch> (assuming I saved it), so not much difference.  I
woudl be interested to get your mutt config though, that may save me
some effort when reviewing a patch.

>>
>For me it's a bit different. Since I always read email on my laptop 
>but do development on a box in my cube via ssh/screen, the 
>email-to-dev-env workflow is a bit more convoluted, unfortunately.
>
>In thunderbird I save the message, then scp it to my dev env, then I 
>run 'git am' on it. I'm sure the response to this by others would be 
>that I need to switch my email reading to mutt via ssh/screen.
>>-- Matt
>Scott
>

Clearly that is the answer, and I was about to reply with that  ;)

Matt, overall this looks reasonably similar to how I work, with the
noted differences.

-j



More information about the aeolus-devel mailing list