> Note that the "don't rebase" (as usual) only concerns your published tree. > You can certainly rebase non-published stuff. > > As to the "don't base your development on somebody who does" - base your That's not practical for me. Maybe it's for you, but it doesn't really work if you're sufficiently down the food tree. You just have to work with what other maintainers have and you can't really yell at them when they do something inconvenient like you do all the time, because they just ignore you then. > development either on my tree (I don't rebase) or talk to the d*ck-head > that you _want_ to work with, but who rebases. > > > > Remember how I told you that you should never rebase? > > > > I suspect your recommendation does not match real world git use. > > A lot of the trees don't rebase. The rest of the trees may not realize That's not my experience, sorry (even on other other trees than linux-next, linux-next was just an example). e.g. the original ACPI tree did it, the x86 tree jungle does it, most of the other architecture trees do it, the networking tree does it. etc.etc. Then for linux-next it's reasonable to say that one shouldn't do development on top of it, but still if there is supposed to be a tester base for it it requires at least reasonable support in git for regular read-only download and right now that support is at best obscure and unobvious (to avoid stronger words) > And linux-next has _never_ been appropriate as a development base for > other reasons, so forget about linux-next. It's to find merge conflicts > and possibly boot/test failures of the trees it contains, not for anything > else. Well it sounds like most people except you get it "wrong". Or maybe it's more that your intended usage model just does not match what people really do. -Andi -- 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
