keeping software forks under MacPorts repo?

[Christopher Jones]

> On 9 Nov 2019, at 5:06 pm, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> On Nov 9, 2019, at 11:00, Mojca Miklavec wrote:
>> 
>> But we would probably want to
>> prefix the repository names (something like "fork_qt", "fork_llvm") to
>> clearly distinguish them from our main repositories.
> 
> I wouldn't necessarily suggest doing that. We're not forking in order to diverge from upstream and evolve the software into a different product. We're only doing it to apply bug fixes. 

I agree. changing the name is unnecessary and for me would in itself be confusing.

forking is standard in GitHub, and never changes the name of the repo. e.g.

https://github.com/cjones051073/macports-ports <https://github.com/cjones051073/macports-ports>

is my fork of

https://github.com/macports/macports-ports <https://github.com/macports/macports-ports>

and it is clearly stated at the top this is the case. I see no benefit in changing it by appending “fork_”.

Chris

> 
> 
>> Is it possible to
>> set up a cron job to keep the upstream branches and tags fully up to
>> date (but without deleting our own branches, and ideally without
>> accumulating deleted upstream branches)?
> 
> Given how pervasive git is today, there probably is. But syncing out fork with upstream seems like a normal task that a developer would be expected to do manually at their convenience. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20191109/40982d97/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1930 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20191109/40982d97/attachment.bin>