Re: documentation for committing with git
От | Magnus Hagander |
---|---|
Тема | Re: documentation for committing with git |
Дата | |
Msg-id | AANLkTikN5K8zydmtOQTfurv3D9y_7HZqD0f26bZKIFXr@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: documentation for committing with git (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: documentation for committing with git
Re: documentation for committing with git |
Список | pgsql-hackers |
On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan <andrew@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/
В списке pgsql-hackers по дате отправления: