On Mon, Mar 27, 2017 at 3:22 PM, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > > It's a time somehow painfull, I agree. It's why I try also push > the serie on github when the serie is worth of it (and complete). > in this case you can find everything at: > https://github.com/lucvoo/sparse/commits/llvm-fixes-v6 > > (and yes, this tree contains a few more patches, not in the serie > already submitted but not yet in sparse-next). I do wish that sparse would use more of a real git workflow, instead of just applying patches. Sending out patches to a mailing list is _wonderful_ for actually doing code review and making people *aware* of what's going on, but it's not a great maintenance model. It doesn't scale, and it makes for lots of maintainer work. Particularly with somebody like Luc, who sends involved patch series for core stuff and knows what he is doing, I think Chris could just do git merges, and lower the maintenance overhead a lot. NOTE! If you do git merges using the github interface, things often go south *very* quickly. github likes to do "merges" using rebase, probably because it caters to projects who don't understand about the whole "keep a sane history". So it's really really easy to use github in ways that interact really badly with good git workflows. But you *can* do merges entirely using github, if you actually know what you're doing and are careful to not do rebasing merges with core contributors (using rebase for the occasional small patch series from random fly-by contributors is ok, but I think even then github screws up signed-off chains). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
