Re: git gururs

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

In response to

Browse pgsql-jdbc by date

  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