[OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 14:29, Javier Domingo Cansino wrote:
>     While it works fine for packages, I don't think the pull request stuff
>     is very usable for OpenWrt core, which has a more centralized
>     development model.
>     One reason why we haven't moved the main repo to git yet is that we lose
>     the advantage of having revision numbers that propagate to the firmware,
>     even with builds from a forked repository where some commits have been
>     added on top.
>     If we do everything in git, we either have to constantly remember to tag
>     revisions, or we will lose valuable information when users report bugs
>     with forked repos.
>     I also happen to like linear history very much, and SVN enforces that ;)
> 
> 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. 
> 
> I don't fully understand the 'remember to tag revision' thing.
Right now, the revision number (r<something>) is really useful to figure
out what particular openwrt version is being used, when people report
bugs. The commit hash cannot be used as a replacement, since it might be
one that isn't present in the official repo.
When using tags as a starting point (via git describe), somebody has to
create those tags, which is cumbersome (and would mean adding lots of
useless ones).

>     I still believe for our maintenance process it's a bad idea to maintain
>     the kernel as a separate git repository. With generic changes, it's easy
>     to lose track of what patch has been applied in which branch, and
>     syncing them can be annoying with rebases.
>     Also, pulling changes is going to be confusing for users as well, since
>     we will have to constantly rebase branches.
> 
>  
> 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.
Well, we have per-target kernel patches. Patches from different targets
might conflict with each other, or might break unrelated targets.
Dealing with that would mean either carefully reviewing every single
target patch to avoid negative side effects for other targets, or
maintaining one branch per target.
For both variants, the amount of extra work this creates in my opinion
vastly outweighs the benefits of using git for the kernel tree.

> 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.
If we keep rebasing, people get confused when working on the tree and
running git pull.

> Making maintainable the support for several different versions of
> kernel, each one on it's branch, forking from the official repo.
I'm open to changing my mind if I see some compelling arguments, but
right now I believe the extra maintenance cost vastly outweighs the
potential benefits.

- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel