Magnus Hagander wrote:
Personally, I have a strong opinion that for everything but totally trivial
patches, the committer should create a short-lived work branch where all the
work is done, and then do a squash merge back to the main branch, which is
then pushed. This pattern is not mentioned at all. In my experience, it is
essential, especially if you're working on more than one thing at a time, as
many people often are.
Uh, that's going to create an actual merge commit, no? Or you mean
squash-merge-but-only-fast-forward?
Yes, exactly that. Something like:
git checkout -b myworkbranch
... work, test, commit, rinse, lather repeat ...
git checkout RELn_m_STABLE
git pull
git merge --squash myworkbranch
git push
I *think* the docs is based off the pattern of the committer having
two repositories - one for his own work, one for comitting, much like
I assume all of us have today in cvs.
So then what? After you've done your work you'll still need to pull the
stuff somehow into your commit tree. I don't think this will buy you a
lot. I usually clone the whole CVS tree for non-trivial work, but I'm
not sure that's an ideal work pattern.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
