search

BPI-SINOVOIP / pi-linux

linux kernel for pi
10 stars 4 forks source link

Please rebase k1 patches on top of official 6.1.15 commit #2

Open dlan17 opened 1 month ago

dlan17 commented 1 month ago

Currently, the linux-6.1.15-k1 branch[1] has one blunt commit which is a cut-off of v6.1.15, this will result huge git download traffic (3GB data), bring frustrating bad experience for users..

Releasing patches on top of stable kernel tree's official 6.1.15 commit[2], would allow users to fetch code from any kernel mirror repos, then later only download k1 patches (only the diff) from BPI repo..

[1] https://github.com/BPI-SINOVOIP/pi-linux/tree/linux-6.1.15-k1 [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.1.15&id=42616e0f09fb4e9a6c59892a227f7bdefbd2d6d3

The-going commented 1 month ago

My actions were according to the algorithm:

> mkdir -p BPI-SINOVOIP/pi-linux
> cd BPI-SINOVOIP/pi-linux/
> git init .
> git remote add -t linux-6.1.15-k1 bpi-sinovoip https://github.com/BPI-SINOVOIP/pi-linux
> git fetch bpi-sinovoip

The download size was: 100% (86129/86129), 245.04 MiB

dlan17 commented 1 month ago

The download size was: 100% (86129/86129), 245.04 MiB

oh, 3GB is probably not the correct figure which may include all files.. but in fact 245M is still too large, with my proposal it should only download additional ~20M diff

The-going commented 1 month ago

only download additional ~20M diff

I completely agree with you.

But then the changes must be applied to linux tag v6.1.15 or the changes can be applied to a shallow clone of this branch: linux-6.1.y which contains commits only in the range v6.1..v6.1.15. I think that's what you meant.

@BPI-SINOVOIP Do you think it is possible to make changes that go over the top will be small, and not one big commit that changes 3200 files. In this case, they can be rebased by periodically updating the repository. All changes will always remain on top.

The-going commented 1 month ago

@BPI-SINOVOIP Do you think it is possible to make changes that go over the top will be small, and not one big commit that changes 3200 files.

I want to be understood correctly. In order to provide support, I will have to split this large commit myself. But in this case, only one author will be listed in each patch (commit), which obviously violates copyright and violates the history of changes.

The technology we use is similar to the command "git pull --rebase=true". The only difference is that the patches described in the file series are applied.

pyavitz commented 1 month ago

This I would assume is the bulk of the problem; https://gitee.com/bianbu-linux/linux-6.1 Which also happens to be more up to date than this repo.

The-going commented 1 month ago

This I would assume is the bulk of the problem; https://gitee.com/bianbu-linux/linux-6.1 Which also happens to be more up to date than this repo.

I've already started splitting this big commit into smaller ones. But it looks like you're right. I will use the original repository as a basis. That is, I first create a shallow clone from kernel.org linux branches are 6.1-y. Next, I create a branch with a new name from this one and will apply the patches received after splitting to it. This new branch will always be rebased and we will be able to extract a clean set of patches for Armbian from it.

pyavitz commented 1 month ago

This I would assume is the bulk of the problem; https://gitee.com/bianbu-linux/linux-6.1 Which also happens to be more up to date than this repo.

I've already started splitting this big commit into smaller ones. But it looks like you're right. I will use the original repository as a basis. That is, I first create a shallow clone from kernel.org linux branches are 6.1-y. Next, I create a branch with a new name from this one and will apply the patches received after splitting to it. This new branch will always be rebased and we will be able to extract a clean set of patches for Armbian from it.

Sounds good.