On Wed, May 09, 2012 at 02:08:47PM -0400, Jeff Layton wrote: > For "normal" branches that you expect people to pull, I agree. For > linux-next though, it really doesn't matter too much since it gets > re-created from scratch every day. > > Rewriting history is explicitly ok there, but you do of course want > that branch to be bisectable if at all possible in order to make it > easier to track down regressions. > > OTOH, if someone says "I got a panic on linux-next from on last > Thursday", it might be tough to know what was in that pull if you're > changing the history regularly. It is a bit of a balancing act, I guess. Yeah. So the way I currently do it, in case it's of any use: I have a for-next branch in my public repo, and a for-next-incoming in my local repo. The latter gets rebased, the former doesn't. I apply stuff to for-next-incoming when I start considering it, but I rearrange and rewrite it on top of for-next all the time. Every now and then I do a gitk for-next..for-next-incoming and look for the longest initial set of commits that: - are based on patches that have been posted at least 24 hours. (Exceptions for something urgent or trivial.) - have passed any required review. I run about a half hour of simple automated regression tests on the commit at the top of that initial piece and push it to for-3.5. I try to do that as I go along, rather than waiting a month and then pushing a bunch out at once. There are some things that -next testing routinely catches that I still miss (cross-compiles or various config options). I should probably add more of those to my tests. But so far that's been close enough to bisectable that I haven't felt a strong need to break my self-imposed rule and rebase. > In any case, for some background...the problem we're trying to solve > here is that patches sit on linux-cifs mailing list with no activity > for months when they should be soaking in linux-next. So we're trying > to come up with a workflow that allows us to get them into linux-next > in a more timely fashion. If that requires not using an append-only > branch, I'm ok with that... Makes sense. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
