From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com> |
Cc: | Dave Cramer <pg(at)fastcrypt(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: git gururs |
Date: | 2012-11-03 07:34:29 |
Message-ID: | 5094C905.5060505@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 11/02/2012 03:13 AM, Maciek Sakrejda wrote:
> Git cherry-pick is probably the right tool for this. Commit on master,
> and cherry-pick that commit from all branches you want to back-patch
> to (note that due to the way git names commits, you can just say "git
> cherry-pick master" to grab the latest commit from master). If the
> most recent release branch has not diverged from master (that is, all
> commits on master are also on this branch), you can just merge master
> into the branch (a fast-forward merge) to make it current. It will do
> the same thing as a cherry-pick, but more simply.
>
> This is fairly simple, but just as importantly, it keeps the semantics
> you want: you are making changes to master (trunk), but back-porting
> them to select branches. It also keeps the commit history fairly
> clean.
I'd second that. git cherry-pick is very useful. The other tool I use a
fair bit is `git merge --squash` when I want to compact the contents of
a messy working branch down to a single commit. I usually prefer to `git
rebase --interactive` the working branch to clean it up then `git merge`
it into the target branch, but that isn't always practical.
The main thing I find to be important is to maintain clear, discrete
units of work, not change sets that fix X and Y and add Z. That way you
can easily keep track of the fact that change <x> is in branches A, B and C.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2012-11-03 07:35:58 | Re: Buildfarm test failure |
Previous Message | Dave Cramer | 2012-11-02 20:10:49 | Re: 9.1-903 JDBC 3 Download |