{"id":256,"date":"2013-11-21T15:11:10","date_gmt":"2013-11-21T20:11:10","guid":{"rendered":"http:\/\/blog.mozilla.org\/nfroyd\/?p=256"},"modified":"2013-11-21T15:11:10","modified_gmt":"2013-11-21T20:11:10","slug":"my-git-workflow","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nfroyd\/2013\/11\/21\/my-git-workflow\/","title":{"rendered":"my git workflow"},"content":{"rendered":"

Mark Hammond recently started an etherpad about how people work with git<\/a>. Rather than commenting there, I thought I’d blog about my workflow instead.<\/p>\n

First piece: magit<\/a>.\u00a0 If you use emacs and git, and you don’t use magit, you are missing out.\u00a0 Highly recommended.\u00a0 I don’t use the git command line for common operations anymore; I do everything through magit.\u00a0 magit’s interactive staging is a big improvement over git add -i<\/tt>: you can stage files, hunks, or individual regions selectable by normal Emacs point-and-mark.\u00a0 I also really like magit’s rebasing support, as I use rebase a lot.<\/p>\n

Second piece: git-bz-moz<\/a>.\u00a0 I was reluctant to use this at first, but it’s been a huge boon in posting patches directly from my editor.\u00a0 Setup is pretty straightforward; I have:<\/p>\n

[bz]\r\n\tfirefox-profile = other\r\n\tdefault-tracker = bugzilla.mozilla.org\r\n\tdefault-product = General\r\n\tdefault-component = Core\r\n        default-assigned-to = nfroyd@mozilla.com\r\n\tadd-url-method = subject-prepend:Bug %d -<\/pre>\n
in my ~\/.gitconfig<\/tt>, and git-bz<\/tt> is smart enough to go grovel through my Firefox profile to get my Bugzilla login information. Having it auto-mark bugs with the appropriate bug numbers during export is also helpful. (It’s smart enough to remove them when adding descriptions for the patches in Bugzilla.) My only complaint is that attaching patches to a bug doesn’t auto-assign the bug to you, like like hg bzexport<\/tt> does.<\/p>\n
Third piece: I wrote a script I call export-patches<\/a> for sending stuff to try, committing to inbound, and exporting patches for uplift.\u00a0 (I used to use it for formatting patches for bugzilla, but stopped doing that after learning git-bz<\/tt>.)\u00a0 I can push things to try:<\/p>\n
export-patches -h ${mc_repo} -t '-b do -p all -u all -t none' ${start}..${end}<\/pre>\n
or push things to inbound:<\/p>\n
export-patches -h ${mi_repo} -r ehsan -b 1 -c ${start}..${end}<\/pre>\n
It supports per-patch reviewers, too (along with a couple of other things I won’t demonstrate here):<\/p>\n
export-patches -h ${mi_repo} -r bz:glandium -b 1 -c ${start}..${end}<\/pre>\n
The -b 1<\/tt> convention is leftover from when I wasn’t tagging my patches with bug numbers until commit.\u00a0 (The script complains if bug numbers aren’t specified on the command line for commits.)\u00a0 git-bz<\/tt> absolved me of doing that. I should probably fix that.<\/p>\n
Third-and-a-half piece: export-patches takes some pains (not as many as it could) to ensure that whatever repo I’m using gets its patch queue wiped if things fail.\u00a0 Less monkeying around with mercurial commands is a win in my book.<\/p>\n
Fourth piece: One big branch of work. I used to use separate branches for bugs. However, I found that I was working on enough things simultaneously that switching between branches, rebasing if necessary, clobbering if necessary (often), and so forth was just too disruptive for day-to-day stuff. I’ll use branches if I have really disruptive things that I can’t integrate piecemeal into my one big branch, but generally everything goes into one branch. I ensure things build locally and I make occasional efforts to ensure appropriate tests still work locally, but try is where most of my testing gets done nowadays.<\/p>\n
Fourth-and-a-half piece: I never checkout master<\/code>.\u00a0 I always fetch origin<\/code>, and then rebase off of origin\/master<\/code>.\u00a0 My branches all track origin\/master<\/code>, so magit will tell me exactly what commits I have remaining to go upstream.<\/p>\n
Annoyances: If I commit patches, then those patches get backed out, when I next pull from mozilla-central and rebase, the patches that I pushed disappear from my branch. I haven’t looked too deeply into why this happens, but I’d really like to fix that.<\/p>\n","protected":false},"excerpt":{"rendered":"
Mark Hammond recently started an etherpad about how people work with git. Rather than commenting there, I thought I’d blog about my workflow instead. First piece: magit.\u00a0 If you use emacs and git, and you don’t use magit, you are missing out.\u00a0 Highly recommended.\u00a0 I don’t use the git command line for common operations anymore; […]<\/p>\n","protected":false},"author":320,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/256"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/users\/320"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/comments?post=256"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/256\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/media?parent=256"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/categories?post=256"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/tags?post=256"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}