I’d like to discuss the possibility of adding support for git patching packages.
This would solve the following problem:
You want to add library A to your project. It’s open source and mostly does what it says, but has a small bug. You fix the bug but the library’s developer is not responsive or doesn’t want to add the fix right away. Or, maybe you add a small modification to fit your requirements. Either case, you would like to have a way to apply your patch but also keep the original repo linked.
Both text (i.e. `empty_name.patch`) and local/remote url patches could be supported. For the urls, they could be contained in the package manifest. The files could follow the directory naming convention (maybe `Patches`?)
The only way I can think of achieving something similar would be to separately clone project A, make the changes and maintain yet another repo. This, in my opinion, should be avoided.
setting up a repository with a custom branch is so easy today, I don't think that I personally would use this feature (actually, I'm quite sure for most developers it is easier to fork a repo than to create a patch…).
That said, the feature wouldn't hurt me (although I would be quite happy if the Kernel for my Raspi would have a proper repo instead of an arcane buildscript that applies a series of patches)
That makes sense, having a forked repo with your own branch works best for situations like you described, significant or multiple changes to the original repo. I wouldn't use arcane patches either for a custom kernel.
However, I recently had to make a very tiny change to a repo, one line of code and it felt wrong to loose the ability to draw from the original upstream because of it.
It was after all, such a minor change that could have been applied after each upstream pull. I know, this could lead to merging conflicts if you support arbitrary versions (x.x +), however, merging your forked repo would lead to the same thing, but remotely (another thing to worry about)
To be honest, I'm not convinced either this would be the best course of action, but it does build upon git, and it does help in certain situations. I'm not sure how often their occurance is tho
- V
···
Sent from my iPhone
On 11 Jan 2016, at 01:20, Tino Heth <2th@gmx.de> wrote:
Hello Valentin,
setting up a repository with a custom branch is so easy today, I don't think that I personally would use this feature (actually, I'm quite sure for most developers it is easier to fork a repo than to create a patch…).
That said, the feature wouldn't hurt me (although I would be quite happy if the Kernel for my Raspi would have a proper repo instead of an arcane buildscript that applies a series of patches)
I’d like to discuss the possibility of adding support for git patching packages.
This would solve the following problem:
You want to add library A to your project. It’s open source and mostly does what it says, but has a small bug. You fix the bug but the library’s developer is not responsive or doesn’t want to add the fix right away. Or, maybe you add a small modification to fit your requirements. Either case, you would like to have a way to apply your patch but also keep the original repo linked.
Both text (i.e. `empty_name.patch`) and local/remote url patches could be supported. For the urls, they could be contained in the package manifest. The files could follow the directory naming convention (maybe `Patches`?)
The only way I can think of achieving something similar would be to separately clone project A, make the changes and maintain yet another repo. This, in my opinion, should be avoided.
Please let me know what you think about it.
My perspective here is:
1) You can do this by checking in your Packages directory, once this is a supported feature (which is intended) SwiftPM will warn that your Packages directory differs from that of upstream.
2) You can fork and change which fork is used as per our lockfile proposal
3) Add a Swift Extensions in your own modules if possible
···
My perspective here is:
1) You can do this by checking in your Packages directory, once this is a supported feature (which is intended) SwiftPM will warn that your Packages directory differs from that of upstream.
2) You can fork and change which fork is used as per our lockfile proposal
1) - sounds good. Will it fast forward any changes if possible (or attempt merging at all) on demand? Is there a proposal re this?
···
Sent from my iPhone
On 13 Jan 2016, at 02:53, Max Howell <max.howell@apple.com> wrote:
3) Add a Swift Extensions in your own modules if possible
My perspective here is:
1) You can do this by checking in your Packages directory, once this is a supported feature (which is intended) SwiftPM will warn that your Packages directory differs from that of upstream.
2) You can fork and change which fork is used as per our lockfile proposal
1) - sounds good. Will it fast forward any changes if possible (or attempt merging at all) on demand? Is there a proposal re this?
The stuff in Packages are actual clones, so you can manage your own merging. However I should think the default update command can try to do it for you, yes.