git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git: new feature suggestion

From
Stefan Beller <sbeller@google.com>
Date
Jan 19, 2017, 22:03 UTC
Message-ID
<CAGZ79kZ3g+J5=ZmP8zDCK8zBwMc7SwLdmgyB3Sab8qkTE=enhQ@mail.gmail.com>
In-Reply-To
<5207b04e-5e80-7100-4328-7e87ee619aea@synopsys.com>
On Thu, Jan 19, 2017 at 1:51 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
Show 61 quoted lines
> Às 7:16 PM de 1/19/2017, Linus Torvalds escreveu:
>> On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>
>>> I am currently facing some challenges in one of Linux subsystems where a rename
>>> of a set of folders and files would be the perfect scenario for future
>>> development, but the suggestion is not accepted, not because it's not correct,
>>> but because it makes the maintainer life harder in backporting bug fixes and new
>>> features to older kernel versions and because it is not easy to follow the
>>> renamed file/folder history from the kernel.org history logs.
>>
>> Honestly, that's less of a git issue, and more of a "patch will not
>> apply across versions" issue.
>>
>> No amount of rename detection will ever fix that, simply because the
>> rename hadn't even _happened_ in the old versions that things get
>> backported to.
>>
>> ("git cherry-pick" can do a merge resolution and thus do "backwards"
>> renaming too, so tooling can definitely help, but it still ends up
>> meaning that even trivial patches are no longer the _same_ trivial
>> patch across versions).
>>
>> So renaming things increases maintainer workloads in those situations
>> regardless of any tooling issues.
>>
>> (You may also be referring to the mellanox mess, where this issue is
>> very much exacerbated by having different groups working on the same
>> thing, and maintainers having very much a "I will not take _anything_
>> from any of the groups that makes my life more complicated" model,
>> because those groups fucked up so much in the past).
>>
>> In other words, quite often issues are about workflows rather than
>> tools. The networking layer probably has more of this, because David
>> actually does the backports himself, so he _really_ doesn't want to
>> complicate things.
>
> I totally understand David' side! Synopsys is a well-known IP Vendor, and for a
> long time its focus was the IP only. Knowadays the strategy has changed and
> Synopsys is very keen to help in Open Source, namelly Linux, developing the
> drivers for new IP Cores and participating in the improvement of existing ones.
> I am part of the team that has that job.
>
> In USB and PCI subystems developers created common Synopsys drivers (focused on
> the HW IP) and so today they are massively used by all the SoC that use Synopsys
> IP.
>
> In the network subsystem, there are some drivers that target the same IP but
> were made by different companies. stmmac is an excelent driver for Synopsys MAC
> 10/100/1000/QOS IPs, but there was another driver made by AXIS driver that also
> targeted the QOS IP. We detected that issue and merged the AXIS specific driver
> ops to stmmac, and nowadays, AXIS uses stmmac. So less drivers to maintain!
>
> The idea that was rejected consisted of renaming stmicro/stmmac to dwc/stmmac
> and to have dwc (designware controllers) as the official driver spot for
> Synopsys Ethernet IPs.
> There is another example of duplication, which is AMD' and Samsung' XGMAC
> driver, targeting the same Synopsys XGMAC IP.
>
> I am giving this examples because although the refactor adds work for
> backporting, it reduces the maintenance since we would have less duplicated
> drivers as we have today.

This sounds as if the code in question would only receive backports for a specific time (determined by HW lifecycle, maintenance life cycle and such).

So I wonder if this could be solved by not just renaming but additionally adding a symbolic link, such that the files in question seem to appear twice on the file system. Then backports ought to be applicable (hoping git-am doesn't choke on symlinks), and after a while once the there no backports any more (due to life cycle reasons), remove the link?

This also sounds like a kind of problem, that others have run into before, how did they solve it?

Thanks, Stefan

Show 8 quoted lines
>
> Thanks,
> Joao
>
>
>>                Linus
>>
>
Previous: Joao PintoNext: Joao Pinto
Message 11 of 15 in “Git: new feature suggestion”
  1. Joao PintoJan 18, 2017
  2. Stefan BellerJan 18, 2017
  3. Joao PintoJan 18, 2017
  4. Konstantin KhomoutovJan 19, 2017
  5. Junio C HamanoJan 19, 2017
  6. Joao PintoJan 19, 2017
  7. Linus TorvaldsJan 19, 2017
  8. Joao PintoJan 19, 2017
  9. Linus TorvaldsJan 19, 2017
  10. Joao PintoJan 19, 2017
  11. Stefan BellerJan 19, 2017
  12. Joao PintoJan 20, 2017
  13. Jakub NarębskiJan 19, 2017
  14. Linus TorvaldsJan 20, 2017
  15. Jakub NarębskiJan 20, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.