Re: pl/python improvements
От | Jan Urbański |
---|---|
Тема | Re: pl/python improvements |
Дата | |
Msg-id | 4CFEBBAB.8050500@wulczer.org обсуждение исходный текст |
Ответ на | Re: pl/python improvements (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: pl/python improvements
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: