Hi all,
Today's linux-next merge of the net tree got a conflict in:
drivers/net/can/usb/peak_usb/pcan_usb_fd.c
between commit:
6417f03132a6 ("module: remove never implemented MODULE_SUPPORTED_DEVICE")
from Linus' tree and commit:
59ec7b89ed3e ("can: peak_usb: add forgotten supported devices")
from the net tree.
I fixed it up (I just removed the new MODULE_SUPPORTED_DEVICE() lines)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
On Fri, Mar 19, 2021 at 08:29:39AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net tree got a conflict in:
>
> drivers/net/can/usb/peak_usb/pcan_usb_fd.c
>
> between commit:
>
> 6417f03132a6 ("module: remove never implemented MODULE_SUPPORTED_DEVICE")
>
> from Linus' tree and commit:
>
> 59ec7b89ed3e ("can: peak_usb: add forgotten supported devices")
>
> from the net tree.
>
> I fixed it up (I just removed the new MODULE_SUPPORTED_DEVICE() lines)
> and can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Thanks Stephen, the code should be deleted and commit 59ec7b89ed3e needs
to be reverted.
>
> --
> Cheers,
> Stephen Rothwell
On 3/19/21 4:55 PM, Leon Romanovsky wrote:
> On Fri, Mar 19, 2021 at 08:29:39AM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the net tree got a conflict in:
>>
>> drivers/net/can/usb/peak_usb/pcan_usb_fd.c
>>
>> between commit:
>>
>> 6417f03132a6 ("module: remove never implemented MODULE_SUPPORTED_DEVICE")
>>
>> from Linus' tree and commit:
>>
>> 59ec7b89ed3e ("can: peak_usb: add forgotten supported devices")
>>
>> from the net tree.
>>
>> I fixed it up (I just removed the new MODULE_SUPPORTED_DEVICE() lines)
>> and can carry the fix as necessary. This is now fixed as far as linux-next
>> is concerned, but any non trivial conflicts should be mentioned to your
>> upstream maintainer when your tree is submitted for merging. You may
>> also want to consider cooperating with the maintainer of the conflicting
>> tree to minimise any particularly complex conflicts.
>
> Thanks Stephen, the code should be deleted and commit 59ec7b89ed3e needs
> to be reverted.
Good idea. I'll send a pull request to David and Jakub.
https://lore.kernel.org/r/[email protected]
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Sat, Mar 20, 2021 at 12:28 PM Marc Kleine-Budde <[email protected]> wrote:
>
> Good idea. I'll send a pull request to David and Jakub.
I don't think the revert is necessary. The conflict is so trivial that
it doesn't really matter.
Conflicts like this that are local and obvious aren't really
problematic. Any maintainer pulling git trees will have seen them and
is used to them (admittedly probably me and Stephen more than most,
but still).
The conflicts that can be pretty painful and might be worth worrying
about ahead of merge time - or at least let the maintainer/me know
about loudly when you ask them/me to pull - are the ones that might
not even show up as a file conflict. The conflict might be purely
semantic rather than some simple "changed lines next to each other"
kind of thing.
Often even those are trivial, but they might fly under the radar. Many
of them cause build issues (think "changed arguments to or renamed a
function" on one side, "added new use of function" on the other side),
but not all do, And even if they do, they might do so only under
certain configurations and architectures, of course.
And occasionally there are conflicts that are just so *big* that they
are painful to work through (things like renaming variables and moving
code on one side, and then non-trivial changes on the other side).
They can look particularly scary when you see the conflict diff, but
on the whole it's unusual that it's a real problem. I reasonably often
ask people to verify my merge "just in case", but it's seldom actually
a big issue. I don't remember the last time I actually went back to a
maintainer and said "ok, this looks too nasty, please actively help me
out".
In fact, the most common conflict problem is not that the conflict is
_hard_ - it's that some coding patterns are just _annoying_ when they
cause conflicts.
Things like big whitespace cleanups across whole subdirectories get
_really_ old as you're working on the fifth file that has a conflict
due to the same silly syntactic change.
But something like this that just removes the
MODULE_SUPPORTED_DEVICE() thing that basically never gets touched
anyway, and we happened to be unlucky in *one* file? Not a worry at
all.
Linus
On Sat, Mar 20, 2021 at 12:42:06PM -0700, Linus Torvalds wrote:
> On Sat, Mar 20, 2021 at 12:28 PM Marc Kleine-Budde <[email protected]> wrote:
> >
> > Good idea. I'll send a pull request to David and Jakub.
>
> I don't think the revert is necessary. The conflict is so trivial that
> it doesn't really matter.
<...>
> But something like this that just removes the
> MODULE_SUPPORTED_DEVICE() thing that basically never gets touched
> anyway, and we happened to be unlucky in *one* file? Not a worry at
> all.
For me this specific revert is a way to reduce the overhead from the maintainer
when they prepare PRs. At least for me, PRs are most time consuming tasks.
No patch - no conflict - less worries.
Thanks