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)
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.
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.
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?
-- Matt
On Tue, 10 Apr 2012 15:19:03 -0400, Matt Wagner matt.wagner@redhat.com 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)
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.
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.
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?
-- Matt
I just want to jump in before this discussion gets too deep and let it be known that I'm currently writing up a proposal for some pretty drastic changes in our git/release workflow. I don't have anything to share yet; I want to make sure to thoroughly explain and justify why I think it should work this way. Hopefully tomorrow afternoon I'll have my first draft up.
Carry on :)
On Tue, Apr 10, 2012 at 03:53:40PM -0400, John Eckersberg wrote:
I just want to jump in before this discussion gets too deep and let it be known that I'm currently writing up a proposal for some pretty drastic changes in our git/release workflow. I don't have anything to share yet; I want to make sure to thoroughly explain and justify why I think it should work this way. Hopefully tomorrow afternoon I'll have my first draft up.
Carry on :)
I probably didn't pick the best time to bring this up, then. D'oh!
Hopefully most of what I discussed is relatively universal, but maybe it makes sense to let this sit for a bit and revisit it next week or so.
-- Matt
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)
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'
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.
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?
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
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
On Wed, Apr 11, 2012 at 03:55:49PM -0400, Jason Guiditta wrote:
Instead, you can save some effort with: $ git rebase origin/master
I actually knew this was possible, but forget to do it 99% of the time.
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
Nice! I had no idea that this was possible.
Besides saving a step, it eliminates a source of errors -- when I ran git format-patch with multiple patches, I'd sometimes include a newline when copying and pasting, which would send the patch prematurely.
As you just discovered on IRC (but repeating for a larger audience), it seems like the -C trick works with this, too, so "git send-email -C master" will send out an email per commit since master. Nice!
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.
It's nothing overwhelmingly slick. I'll do the normal prepwork (setting up a branch off of master), and then, in mutt, hitting the vertical pipe ("|") when viewing a message will pipe the contents of the entire message to a command. I enter something like "cd ~/aeolus/conductor; git am -s", which applies the patch.
It's interesting to me how many different ways there are to perform what's really just a handful of different tasks.
-- Matt
aeolus-devel@lists.fedorahosted.org