On Fri, Jan 8, 2010 at 11:22 AM, Kevin Grittner
<kevin.gritt...@wicourts.gov> wrote:
> Magnus Hagander <mag...@hagander.net> wrote:
>> On Thu, Jan 7, 2010 at 19:08, Kevin Grittner
>
>>> Robert's advice being the last (and only) offered on the topic,
>>> I'm taking the silence as agreement and have dropped the request
>>> for a "serializable" repository and added one for
>>> /users/kgrittn/postgres instead.
>>
>> ... and i've approved it :-)
>
> Being new to git, I'm hoping someone can suggest a reasonable
> workflow for using this. (I've found no shortage of suggestions for
> possible workflows on the web, but am not clear what to pick or
> synthesize as "best practice" for this particular situation.) A
> little advice may prevent a lot of flailing and false starts, and
> would be much appreciated.
Since we've talked about migrating to git as a project, I hope no one
will mind too much if I answer this on-list, even though it's a bit
OT.
> I assume I want to create a "serializable" branch in this new
> repository and clone that on my desktop.
Well, you'll create it on your desktop (probably with git checkout
master; git checkout -b serializable) and then push it to your
git.postgresql.org repository, actually. You can't really do anything
on the server directly.
> I expect I'll be granting
> write permission on this repository to others, to facilitate
> teamwork on this, but perhaps there's a better way to organize that
> with git.
Another option is you everyone can just push and pull from each other.
But shared write is fine too.
> What would the normal workflows be to:
>
> rebase the postgresql.git clone and the serializable branch on the
> server?
>
> rebase my working copy on my desktop from the serializable branch on
> the server?
>
> integrate work from my desktop to the serializable branch on the
> server when I've hit a state which seems worth sharing with the
> team? (i.e., it compiles and isn't going to break something someone
> else is working on)
Generally the workflow here is going to be that you will:
1. Pull from the master branch in the official postgres.git into your
master branch.
2. Merge (not rebase, if you want to collaborate!) those changes into
your topic branch (serializable).
3. Hack on your topic branch.
4. Push your master and topic branches to users/kgrittn/postgres.git.
For example in my .git/config, I have:
[remote "origin"]
url = git://git.postgresql.org/git/postgresql.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "rhaas"]
url = ssh://g...@git.postgresql.org/users/rhaas/postgres.git
fetch = +refs/heads/*:refs/remotes/rhaas/*
[remote "heikki"]
url = git://git.postgresql.org/git/users/heikki/postgres.git
fetch = +refs/heads/*:refs/remotes/heikki/*
So typically what I do is sort of like this:
git checkout master
git pull (gets changes from upstream)
git checkout -b hackingproject (create new branch)
# hack hack
git commit -a
# hack some more
git commit -a
# ok, time to rebase or merge
git checkout master
git pull
git checkout hackingproject
git merge master (actually, i often rebase, but for this you REALLY
want to merge)
git push rhaas master hackingproject (push to my repo, need a + to
force it if you are rebasing rather than merging)
...other handy stuff...
git log master...hackingproject (see my commits)
git diff master...hackingproject (format as a patch)
...patch gets committed...
git checkout master
git branch -D hackingproject
git push rhaas :hackingproject (delete branch off server)
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
