Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 19 Apr 2017 16:03:45 -0700 | Subject | Re: git process question |
| |
On Wed, Apr 19, 2017 at 3:39 AM, Michael Ellerman <mpe@ellerman.id.au> wrote: > Steven Rostedt <rostedt@goodmis.org> writes: >> >> Would it be OK to cherry pick this change that I send to you, which >> will be based on a commit in your tree, into my development branch >> where I can continue the work on top of the previous development that's >> in linux-next and the fix? > ... >> The alternatives are, > ... >> 2) Merge the development and urgent branches and continue working on >> that. But I understand that you really don't like it when people do that. > ^^^^^^^^^^^^^^^^^^^^ > Is this part actually true? > > I ask because I have done it a few times and thought it was OK in > general if there's a good reason for it.
So I have seen *so* many bad merges from submaintainers that I do discourage them, simply because I see a lot of merges without proper explanations for why the merge happened or what is going on.
It's not that merges like that are necessarily wrong, and they clearly exist, but cherry-picking can actually be the better solution.
If you do merge, make sure to explain why you merge. And you should strive to never do a back-merge of other peoples code, so the "merge into my own development tree" is mainly a good option if the stable branch you are merging only contains your own stuff.
Which it almost never does. People will have started their branches at different points, and the merge suddenly changes a lot of other things than just bringing in a fix. So a small cherry-pick can be the much simpler solution to bring in a fix without bringing in other random stuff.
But things are never entirely black-and-white,. so there's no single "one correct way".
Linus
| |