Re: git gururs

Поиск
Список
Период
Сортировка
От Maciek Sakrejda
Тема Re: git gururs
Дата
Msg-id CAOtHd0AqkT4iUPej1PhNoZrRmA-K0Eyu+FAR+gV6h6TJBMgDmg@mail.gmail.com
обсуждение исходный текст
Ответ на git gururs  (Dave Cramer <pg@fastcrypt.com>)
Ответы Re: git gururs  (Craig Ringer <ringerc@ringerc.id.au>)
Список pgsql-jdbc
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.


В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: git gururs
Следующее
От: Shijun Kong
Дата:
Сообщение: Re: Publish artifacts to Maven central