<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">Right now, the revision number (r<something>) is really useful to figure<br>
out what particular openwrt version is being used, when people report<br>
bugs. The commit hash cannot be used as a replacement, since it might be<br>
one that isn't present in the official repo.<br>
When using tags as a starting point (via git describe), somebody has to<br>
create those tags, which is cumbersome (and would mean adding lots of<br>
useless ones).<br></blockquote><div>The tags would be the major versions and RCs. I don't believe other tags should be used.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, we have per-target kernel patches. Patches from different targets<br>
might conflict with each other, or might break unrelated targets.<br>
Dealing with that would mean either carefully reviewing every single<br>
target patch to avoid negative side effects for other targets, or<br>
maintaining one branch per target.<br>
For both variants, the amount of extra work this creates in my opinion<br>
vastly outweighs the benefits of using git for the kernel tree.<br>
<br>
</blockquote><div>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).</div><div><br></div><div>I find it as repackaging the same project with different patches to add functionality.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm open to changing my mind if I see some compelling arguments, but<br>
right now I believe the extra maintenance cost vastly outweighs the<br>
potential benefits.<br></blockquote><div>My proposal of steps to migrate to git would be.</div><div> 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).</div><div>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.</div><div>Finally, I would go for step 3) check how we can improve the owrt-kernel relationship.</div><div><br></div><div>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.</div></div></div>