[OpenWrt-Devel] SVN to GIT transition

Javier Domingo Cansino javierdo1 at gmail.com
Mon Oct 12 09:09:57 EDT 2015


>
> 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).
>
The tags would be the major versions and RCs. I don't believe other tags
should be used.

Apart from that, I understand that if someone cloned the SVN repo (full svn
history), created it's own server, and developed on top of a given revision
X, the same problem would arise.

I don't find this as a valid argument because that's up to the user. Either
you fork from official owrt and note down the commit you forked in to give
as a reference, or you provide full access to your source code, where you
can actually see when it forked through git merge-base --fork-point.

And of course, you can always automatically generate with help from
git-describe a relative revision from the fork-point. Anyway, it would be
up to the forkers to decide whether they want to rebase their tree or merge
your tree.

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.
>
> I believe that we could find a mix between per kernel version patches and
per target patches. Probably the best would be to treat the openwrt kernel
as a project forking from linux-stable (I believe it's the tarballs you are
currently using), and use that owrt kernel as a base to apply the per
target patches (at the end, each target has it's own specific patches).

I find it as repackaging the same project with different patches to add
functionality.

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.
>
My proposal of steps to migrate to git would be.
 1) openwrt to git, maintaining even the workflow as it is, giving time to
deal with all the differences to svn (such as the relative revision
crafting etc).
Once everyone is comfortable with the git based hosting, I would go for 2)
adapting the workflow to the tools git provides. We would be talking there
about how merge requests are handled, web interfaces, etc.
Finally, I would go for step 3) check how we can improve the owrt-kernel
relationship.

Of course, the 3rd step, if based in my idea, doesn't need to be done
before 1/2. Also, steps 1,2 can be done at once.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20151012/1da7476b/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list