git process question

git process question

[Steven Rostedt]

Hi Linus,

I have a minor bug I found and a fix for it. I'm currently putting it
through the grind and will send it to you for this rc release cycle.

Here's the question. My current linux-next development depends on this
fix. I already posted work to linux-next and do not want to rebase.
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 commit I cherry pick will just evaporate into git mist when you
pull my development branch in the next merge window, as git does the
distilling of commits that are identical. But I want to make sure you
are OK with this plan before I head out and do this.

The alternatives are,

 1) Rebase my current work in linux-next and retest everything from
   scratch. I really don't like doing this.

 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.

Thoughts?

-- Steve

Re: git process question

[Linus Torvalds]

On Fri, Apr 14, 2017 at 3:05 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> 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?

Yes, the occasional duplicated commit due to real reasons is fine. I
get worried if people start using cherry-picking and rebasing as a
_process_, but if the process generally works, and then there's an
occasional need to fix something like this, that's perfectly fine.

          Linus

Re: git process question

[Steven Rostedt]

On Fri, 14 Apr 2017 17:02:34 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, Apr 14, 2017 at 3:05 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > 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?  
> 
> Yes, the occasional duplicated commit due to real reasons is fine. I
> get worried if people start using cherry-picking and rebasing as a
> _process_, but if the process generally works, and then there's an
> occasional need to fix something like this, that's perfectly fine.

Thanks for the response.

So I'll take it that the general idea would be to send you a fix based
on one of my commits that's already in your tree.

Then, if new development that is based on that fix, but nothing I
pushed to linux-next, even if I had already pushed commits to
linux-next, then I would just start the development off of that fix,
and send you multiple pull requests (one for the fix + development
changes, and one with the linux-next development changes).

But if there's a case like this, where I have development changes based
on both the fix and changes I already pushed to linux-next, then I
would just cherry pick that into the development branch and continue.

Sounds good,

-- Steve

Re: git process question

[Michael Ellerman]

Steven Rostedt <rostedt@goodmis.org> writes:

> Hi Linus,
>
> I have a minor bug I found and a fix for it. I'm currently putting it
> through the grind and will send it to you for this rc release cycle.
> 
> Here's the question. My current linux-next development depends on this
> fix. I already posted work to linux-next and do not want to rebase.
> 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.

I make a point of using the same base for my fixes and next branches
(ie. usually some rc), and then I don't fast forward my fixes branch
when Linus merges it, or otherwise put anything in there other than the
actual fixes. That means if I do merge it into next it doesn't bring
anything else with it.

cheers

Re: git process question

[Linus Torvalds]

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