Re: What's cooking in git/spearce.git (topics)

["Shawn O. Pearce" <spearce@spearce.org>]

Theodore Tso <tytso@mit.edu> wrote:
> On Tue, Oct 23, 2007 at 12:46:57AM -0400, Shawn O. Pearce wrote:
> > By merging only individual topics forked from master into next you
> > can merge those individual topics into master at different points
> > in time.  For example db/fetch-pack has been in next for many weeks
> > and hasn't yet merged into master, yet jc/am-quiet was forked after
> > db/fetch-pack started and has already merged into master.
> > 
> > Your way would make jc/am-quiet wait until db/fetch-pack was ready.
> > That's a big risk in the sense that your tree is "blocked" and even
> > simple changes are held up by ones that suddenly became a lot more
> > complex then you originally thought they were going to be.
> 
> Yes, true.  Alternatively, what I've been doing is that if I wasn't
> sure that a particular topic was ready to go to 'master' very shortly
> after it went into 'next', I would never let it go into 'next', but
> rather keep it in 'pu' (which is OK, because pu is constantly getting
> rewound).  But I guess the downside of that is you might get fewer
> testers for the code, because fewer people are probably tracking and
> testing 'pu' as compared to 'next'.
> 
> Right?

Yes, that's a good point.

I think in Git part of the reason less people track pu is because
its very volatile.  Not because of the rewind policy, but becuase
sometimes the code there doesn't work properly so using it for real
"production" work is pretty risky.  On the other hand most of the
code that merges into next has been reasonbly well reviewed and
tested, so following it for "production" work is not as risky.

Junio has in the past proposed rewinding next, especially after a
significant release (e.g. 1.5.3).  A bunch of folks (myself included
if I recall correctly) didn't want to do this, as we create topic
branches locally from things in next and sometimes make commits
over them to improve the topic further.  But I also make topic
branches for things in pu, so I might as well just shut up and
not complain.  :-)

Of course another thought that just came to mind is it is very easy
for me to review next with a

	git log -p --reverse origin/next..build-next

just before merging it into my build branch and compiling it locally.
If next rewound frequently (as pu does) this would be more difficult.

-- 
Shawn.