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

From: Shawn O. Pearce <spearce@spearce.org>
Date: Oct 23, 2007, 04:46 UTC
Message-ID: <20071023044657.GC14735@spearce.org>
In-Reply-To: <20071023043321.GC27132@thunk.org>

Theodore Tso <tytso@mit.edu> wrote:

Show 14 quoted lines

> On Tue, Oct 23, 2007 at 12:05:22AM -0400, Shawn O. Pearce wrote:
> >
> > Yes.  Because 'next' always has commits in it that never appear in
> > 'master'.  So any topic forked from master must merge into next.
> > It can't be a fast-forward.  No forced merging required.
> 
> Why is it the case that 'next' always commits that never appear in
> 'master'.  So far in how I've been doing things that hasn't been the
> case.  When I do a "git checkout master; git merge next", it's always
> been a fast-forward merge. 
> 
> Oh, I see.  That's because if you put some trivial changes in
> 'master', and then pull those changes into next, there will be merge
> commits in 'next' that will never be in 'master.  Is that it?

Exactly.  This of course means that next has been growing in distance
from master for quite some time.  It has well over 1000 commits now
in git.git that aren't in master.  Most of those will never merge
there either.

Show 9 quoted lines

> I had been trying to avoid that case by always putting new commits,
> even trivial ones, into 'next', and then having them drop into
> 'master' at the next cycle; so 'master' was always trailing 'next',
> but they were always the same commit string (i.e., 'master' was always
> a subset of 'next').  
> 
> Aside from the WC script not working right, are there other
> disadvantages to my doing things that way as opposed to the way the
> Junio has been running the git repository?

The reason Junio does what he does is flexibility.

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.

-- 
Shawn.