documentation for committing with git
in [PgSql]
|
From: Robert Haas on 21 Jul 2010 15:26 On Wed, Jul 21, 2010 at 3:23 PM, David Christensen <david(a)endpoint.com> wrote: > > 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. Sure, oops, but I would never do that. I'd stash it or put it on a topic branch. -- 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: Alvaro Herrera on 21 Jul 2010 15:31 Excerpts from Robert Haas's message of mié jul 21 15:26:47 -0400 2010: > > 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. > > Sure, oops, but I would never do that. I'd stash it or put it on a > topic branch. Somebody else will. Please remember you're writing docs that are not for yourself. -- 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: Andrew Dunstan on 21 Jul 2010 15:37 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 > > Note that while anyone is welcome to comment, I mostly care about > whether the document is adequate for our existing committers, rather > than whether someone who is not a committer thinks we should manage > the project differently... that might be an interesting discussion, > but we're theoretically making this switch in about a month, and > getting agreement on changing our current workflow will take about a > decade, so there is not time now to do the latter before we do the > former. So I would ask everyone to consider postponing those > discussions until after we've made the switch and ironed out the > kinks. On the other hand, if you have technical corrections, or if > you have suggestions on how to do the same things better (rather than > suggestions on what to do differently), that would be greatly > appreciated. > Well, either we have a terminology problem or a statement of policy that I'm not sure I agree with, in point 2. IMNSHO, what we need to forbid is commits that are not fast-forward commits, i.e. that do not have the current branch head as an ancestor, ideally as the immediate ancestor. 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. cheers andrew -- 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:39 On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan <andrew(a)dunslane.net> wrote: > > > 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 >> >> Note that while anyone is welcome to comment, I mostly care about >> whether the document is adequate for our existing committers, rather >> than whether someone who is not a committer thinks we should manage >> the project differently... that might be an interesting discussion, >> but we're theoretically making this switch in about a month, and >> getting agreement on changing our current workflow will take about a >> decade, so there is not time now to do the latter before we do the >> former. �So I would ask everyone to consider postponing those >> discussions until after we've made the switch and ironed out the >> kinks. �On the other hand, if you have technical corrections, or if >> you have suggestions on how to do the same things better (rather than >> suggestions on what to do differently), that would be greatly >> appreciated. >> > > Well, either we have a terminology problem or a statement of policy that I'm > not sure I agree with, in point 2. �IMNSHO, what we need to forbid is > commits that are not fast-forward commits, i.e. that do not have the current > branch head as an ancestor, ideally as the immediate ancestor. > > 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? 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. -- �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:44 On Jul 21, 2010, at 2:39 PM, Magnus Hagander wrote: > On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan <andrew(a)dunslane.net> wrote: >> >> >> 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 >>> >>> Note that while anyone is welcome to comment, I mostly care about >>> whether the document is adequate for our existing committers, rather >>> than whether someone who is not a committer thinks we should manage >>> the project differently... that might be an interesting discussion, >>> but we're theoretically making this switch in about a month, and >>> getting agreement on changing our current workflow will take about a >>> decade, so there is not time now to do the latter before we do the >>> former. So I would ask everyone to consider postponing those >>> discussions until after we've made the switch and ironed out the >>> kinks. On the other hand, if you have technical corrections, or if >>> you have suggestions on how to do the same things better (rather than >>> suggestions on what to do differently), that would be greatly >>> appreciated. >>> >> >> Well, either we have a terminology problem or a statement of policy that I'm >> not sure I agree with, in point 2. IMNSHO, what we need to forbid is >> commits that are not fast-forward commits, i.e. that do not have the current >> branch head as an ancestor, ideally as the immediate ancestor. >> >> 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? > > 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. You can also do a rebase after the merge to remove the local merge commit before pushing. I tend to do this anytime I merge a local branch, just to rebase on top of the most recent origin/master. 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
First
|
Prev
|
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 |