Re: Multi-branch committing in git, revisited
От | Bruce Momjian |
---|---|
Тема | Re: Multi-branch committing in git, revisited |
Дата | |
Msg-id | 201009220301.o8M31LS06572@momjian.us обсуждение исходный текст |
Ответ на | Re: Multi-branch committing in git, revisited ("David E. Wheeler" <david@kineticode.com>) |
Ответы |
Re: Multi-branch committing in git, revisited
|
Список | pgsql-hackers |
David E. Wheeler wrote: > On Sep 21, 2010, at 6:20 PM, Tom Lane wrote: > > > While this isn't much worse than what I was used to with CVS, it's > > definitely not better. I think that I could simplify transferring the > > patch back to older branches if I could use git cherry-pick. However, > > that only works on already-committed patches. If I commit in master > > before I start working on 9.0, and so on back, then the commits will be > > separated in time by a significant amount, thus destroying any chance of > > having git_topo_order recognize them as related. So we're back up > > against the problem of git not really understanding the relationships of > > patches in different branches. > > You could commit in each one as you go, cherry-pick, and then in each one > > git reset --soft HEAD^ > > Then they'd all be patched and staged. If I understand correctly, that 'git reset' will mark all branch changes as staged but not committed, and then you can commit all branches at once and push it. Is that right? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: