<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> since <a href="http://kernel.org" rel="noreferrer" target="_blank">kernel.org</a> <<a href="http://kernel.org" rel="noreferrer" target="_blank">http://kernel.org</a>> was compromised. And gitlab/github<br>
> are pretty similar.<br></blockquote><div><br></div><div>Sure, just giving some background on where gitolite was being used and the less-known features it has.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While it works fine for packages, I don't think the pull request stuff<br>
is very usable for OpenWrt core, which has a more centralized<br>
development model.<br>
One reason why we haven't moved the main repo to git yet is that we lose<br>
the advantage of having revision numbers that propagate to the firmware,<br>
even with builds from a forked repository where some commits have been<br>
added on top.<br>
If we do everything in git, we either have to constantly remember to tag<br>
revisions, or we will lose valuable information when users report bugs<br>
with forked repos.<br>
I also happen to like linear history very much, and SVN enforces that ;)<br></blockquote><div>You can enforce linear history by denying history rewrites. It's what they call now protected branches (IIRC), and I think you can really enforce that. Also, you can create hooks to check for tagging info etc. </div><div><br></div><div>I don't fully understand the 'remember to tag revision' thing.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I still believe for our maintenance process it's a bad idea to maintain<br>
the kernel as a separate git repository. With generic changes, it's easy<br>
to lose track of what patch has been applied in which branch, and<br>
syncing them can be annoying with rebases.<br>
Also, pulling changes is going to be confusing for users as well, since<br>
we will have to constantly rebase branches.<br></blockquote><div> </div><div>What I had in mind for the kernel consisted on some similar workflow to the one gitlab uses for their stable branches. You have a branch for each maintained kernel release, and you have all the commit's cherry-picked from the master.</div><div><br></div><div>Of course, you can always use rebase and apply all the patches in order. It is possible to have scripts that actually make sure every patch is applied, letting you substract patch lists, etc.</div><div><br></div><div>Making maintainable the support for several different versions of kernel, each one on it's branch, forking from the official repo.</div></div></div>