documentation for committing with git
in [PgSql]
|
From: Peter Eisentraut on 21 Jul 2010 15:07 On ons, 2010-07-21 at 12:22 -0400, Robert Haas wrote: > At the developer meeting, I promised to do the work of documenting how > committers should use git. So here's a first version. > > http://wiki.postgresql.org/wiki/Committing_with_Git Looks good. Please consolidate this with the Committers page when the day comes. Comments: 3. ... your name and email address must match those configured on the server ==> How do we know what those are? Who controls that? 6. Finally, you must push your changes back to the server. git push This will push changes in all branches you've updated, but only branches that also exist on the remote side will be pushed; thus, you can have local working branches that won't be pushed. ==> This is true, but I have found it saner to configure push.default = tracking, so that only the current branch is pushes. Some people might find that useful. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 21 Jul 2010 15:11 On Wed, Jul 21, 2010 at 21:07, Peter Eisentraut <peter_e(a)gmx.net> wrote: > On ons, 2010-07-21 at 12:22 -0400, Robert Haas wrote: >> At the developer meeting, I promised to do the work of documenting how >> committers should use git. �So here's a first version. >> >> http://wiki.postgresql.org/wiki/Committing_with_Git > > Looks good. �Please consolidate this with the Committers page when the > day comes. > > Comments: > > 3. ... your name and email address must match those configured on the > server > > ==> How do we know what those are? �Who controls that? sysadmins team. It's set up when committers are added, just like today's authormap on the git mirror. Before we set up the system, we'll double check all of them with each committer, of course. > 6. Finally, you must push your changes back to the server. > > git push > > This will push changes in all branches you've updated, but only branches > that also exist on the remote side will be pushed; thus, you can have > local working branches that won't be pushed. > > ==> This is true, but I have found it saner to configure push.default = > tracking, so that only the current branch is pushes. �Some people might > find that useful. Indeed. Why don't I do that more often... +1 on making that a general recommendation, and have people only not do that if they really know what they're doing :-) -- �Magnus Hagander �Me: http://www.hagander.net/ �Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 21 Jul 2010 15:20 On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander <magnus(a)hagander.net> wrote: >> 6. Finally, you must push your changes back to the server. >> >> git push >> >> This will push changes in all branches you've updated, but only branches >> that also exist on the remote side will be pushed; thus, you can have >> local working branches that won't be pushed. >> >> ==> This is true, but I have found it saner to configure push.default = >> tracking, so that only the current branch is pushes. �Some people might >> find that useful. > > Indeed. Why don't I do that more often... > > +1 on making that a general recommendation, and have people only not > do that if they really know what they're doing :-) Hmm, I didn't know about that option. What makes us think that's the behavior people will most often want? Because it doesn't seem like what I want, just for one example... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 21 Jul 2010 15:22 On Wed, Jul 21, 2010 at 21:20, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander <magnus(a)hagander.net> wrote: >>> 6. Finally, you must push your changes back to the server. >>> >>> git push >>> >>> This will push changes in all branches you've updated, but only branches >>> that also exist on the remote side will be pushed; thus, you can have >>> local working branches that won't be pushed. >>> >>> ==> This is true, but I have found it saner to configure push.default = >>> tracking, so that only the current branch is pushes. �Some people might >>> find that useful. >> >> Indeed. Why don't I do that more often... >> >> +1 on making that a general recommendation, and have people only not >> do that if they really know what they're doing :-) > > Hmm, I didn't know about that option. �What makes us think that's the > behavior people will most often want? �Because it doesn't seem like > what I want, just for one example... It'd be what I want for everything *except* when doing backpatching. -- �Magnus Hagander �Me: http://www.hagander.net/ �Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Christensen on 21 Jul 2010 15:23 On Jul 21, 2010, at 2:20 PM, Robert Haas wrote: > On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander <magnus(a)hagander.net> wrote: >>> 6. Finally, you must push your changes back to the server. >>> >>> git push >>> >>> This will push changes in all branches you've updated, but only branches >>> that also exist on the remote side will be pushed; thus, you can have >>> local working branches that won't be pushed. >>> >>> ==> This is true, but I have found it saner to configure push.default = >>> tracking, so that only the current branch is pushes. Some people might >>> find that useful. >> >> Indeed. Why don't I do that more often... >> >> +1 on making that a general recommendation, and have people only not >> do that if they really know what they're doing :-) > > Hmm, I didn't know about that option. What makes us think that's the > behavior people will most often want? Because it doesn't seem like > what I want, just for one example... So you're working on some back branch, and make a WIP commit so you can switch to master to make a quick commit. Create a push on master. Bare git push. WIP commit gets pushed upstream. Oops. Regards, David -- David Christensen End Point Corporation david(a)endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Add column if not exists (CINE) Next: [HACKERS] need more ALTER TABLE guards for typed tables |