On 07/12/10 23:00, Andrew Dunstan wrote:
> On 12/07/2010 04:50 PM, Peter Eisentraut wrote:
>>
>>> The code is on https://github.com/wulczer/postgres, in the plpython
>>> branch. I'll be rebasing it regularly, so don't be surprised by commit
>>> hashes changing.
>> I think rebasing published repositories isn't encouraged.
>
> Indeed. See <http://progit.org/book/ch3-6.html> for example, which says:
>
> *Do not rebase commits that you have pushed to a public repository.*
>
> If you follow that guideline, you’ll be fine. If you don’t, people
> will hate you, and you’ll be scorned by friends and family.
If someone is interested in merging from that branch, I can refrain from
rebasing (just tell me). But I'm really using it just as a patch queue
and pushing to github is a way having an online backup for the changes,
so it's not really a "public repository". It's meant for people who want
to try out the code as it stands today, or see the changes that have
been made and don't care about having to rebase their checkout themselves.
I find developing that way much easier than merging from the master
branch. If I get conflicts I get them on a single commit of mine, not on
the merge commit, which makes them easier to resolve. See
https://github.com/diaspora/diaspora/wiki/Git-Workflow for an example of
that kind of workflow.
Peter suggested having a mail/patch per feature and the way I intend to
do that is instead of having a dozen branches, have one and after I'm
done rebase it interactively to produce incremental patches that apply
to master, each one implementing one feature.
Cheers,
Jan