Postgres Pro
Downloads
Home   >   mailing lists

Thread: git gururs

git gururs

From
Dave Cramer
Date:
I am trying to figure out a rational workflow with the branches here.

I have cloned the project to my own repo so if I want add a patch my current workflow is

1) pull from the real jdbc remote repo to make sure everything is up to date
2) push to my remote to update my remote
3) create a new branch to work on
4) modify code, test commit to my new branch
5) checkout master
6) merge with new branch
7) push to my remote

Now here's where I've run into trouble. 

Can I just push to the real jdbc remote ?

Next how to backpatch. 

just checking out REL9_2_STABLE and merging my new branch doesn't work as I branched off of master. Should I branch off REL9_2_STABLE and then merge to master ???


TIA,
Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

Re: git gururs

From
Maciek Sakrejda
Date:
Dave,

You'll probably get a dozen different answers as different git
workflows work better for different people and different projects, but
this is what I've used on the driver when we maintained a fork of it
at Truviso.

> Can I just push to the real jdbc remote ?

Yes. I prefer to have "private" repositories for everyone on the
project, and one canonical one for the changes, but there's nothing
special about that one. You just never want to edit history (rebase,
filter-branch) that's been sent to that repo (you want to avoid that
in general, but it's a mortal sin to do that in a canonical project
history).

> Next how to backpatch.

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.

Re: git gururs

From
Craig Ringer
Date:
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