Theodore Tso <tytso@xxxxxxx> wrote: > 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. > 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
