Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Dec 5, 2010 at 12:41 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> Well, ISTM that amounts to not having "official topic branches" :-) I agree
>> that this is supposed to be one of git's strengths (or more exactly a
>> strength of distributed SCM's generally). �I don't really see any great
>> value in sanctifying a particular topic branch with some official status.
> I think the value in an official topic branch would be to allow formal
> incremental commit of large patches. In other words, we could decide
> that a commit to the official topic branch must meet the same
> standards of quality normally applied to a commit to the master
> branch, and must go through the same process. It would be understood
> that the topic branch would eventually be merged (with or without
> squash) back into the master branch, but that objections were to be
> raised as pieces were committed to the topic branch, not at merge
> time. The merge itself would require consensus as to timing, but we'd
> agree to take a dim view of "I haven't reviewed anything that's been
> going on here for the last six months but now hate all of it".
Topic branches defined that way seem like a pretty bad idea from here.
They would save no effort at all for committers, because if you're not
allowed to object to something after it's gone into a topic branch, then
it's just like master in terms of having to keep up with changes as they
happen. Moreover, we'd have to keep them in pretty close sync with
master --- otherwise what happens when you discover that some long-ago
change on master breaks the topic branch? So AFAICS this would just
increase the amount of keeping-branches-in-sync dogwork without any
offsetting advantage.
regards, tom lane