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? 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? - Ted - 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
