Bastian, I'm really sorry I've taken so long to look at this. On Tue, 2015-09-08 at 22:52 +0200, Bastian Blank wrote: > Moin > > During the linux packaging BoF at DebConf, Ben asked for usefull > upstream source handling. No compeling ones were mentioned. > > Some years ago (yes, years), I proposed some schema based on submodules, > but never got around to actually implement it. I finally managed to do > an initial implementation. It currently lives in the linux.git in > branch waldi/submodule. > > Main principles: > - source of each featureset is a submodule, using version specific > branches > - orig source via version specific tag
So genorig.py would be replaced with 'git archive'? > Workflow: > - New upstream version > - Rebase old tag on top of new upstream, tag it with the new version There are no tags in the repository you created. Can you add one as an example? Do you think we would tag when updating to a new upstream version, or only when making the first upload with a new orig tarball (allowing for further DFSG changes before uploading)? > - Rebase old main featureset branch on top of new orig tag as new > branch > - Rebase old other featureset branches on top of new main featureset > branch or replace with new base and create new branch > - Record new top commits and update changelog in main repo That's a lot of rebasing, though not so different from what we do now to refresh the patch series. Presumably we would add a script to support this and ensure it is all done properly? The submodules are checked out with detached heads by default. Is your intent that we would override this? I tried this: $ cd source/orig $ git checkout orig/4.2-rc8 For some reason, this deleted upstream files in the working tree - maybe because of the '*' in .gitignore? ... Branch orig/4.2-rc8 set up to track remote branch orig/4.2-rc8 from origin. Switched to a new branch 'orig/4.2-rc8' $ git reset --hard ... $ git checkout -b orig/4.3 Switched to a new branch 'orig/4.3' $ git fetch ~/src/linux refs/tags/v4.3:refs/tags/v4.3 This fetched all tags; maybe I should have just fetched to FETCH_HEAD? ... $ git rebase v4.3 First, rewinding head to replay your work on top of it... Applying: Remove microcode patches for mgsuvd (not enabled in Debian configs) Applying: dvb-usb-af9005: remove, mark as broken Applying: vs6624: remove, mark as broken Applying: Remove and mark as broken: cops Applying: video: Remove nvidiafb and rivafb Applying: Remove the entire firmware directory Applying: Remove: ft1000 Applying: Remove: Non-free RFC $ cd ../none $ git checkout none/4.2-rc8 ... Branch none/4.2-rc8 set up to track remote branch none/4.2-rc8 from origin. Switched to a new branch 'none/4.2-rc8' $ git reset --hard ... $ git checkout -b none/4.3 Switched to a new branch 'none/4.3' $ git fetch ../orig orig/4.3 From ../orig * branch orig/4.3 -> FETCH_HEAD $ git rebase --onto=FETCH_HEAD origin/orig/4.2-rc8 This rebase took a while, but was definitely easier than rebasing with quilt. There are no featuresets to deal with currently. ... $ cd ../.. $ sed -i 's/4.2-rc8/4.3/' .gitmodules $ emacsclient debian/changelog Waiting for Emacs... $ git commit -a -m 'Update to 4.3' $ git push --set-upstream alioth benh/submodule ... $ cd source/orig $ git push --set-upstream origin orig/4.3 This pushed a whole load of tags too. WTF? ... $ cd ../none $ git push --set-upstream origin none/4.3 ... Is it possible to combine those push commands? Is this something else we would need to script? > - Cherry pick patch > - (Make sure the submodules are on the correct branch, otherwise it > will be hard to push changes or they will go to incorrect locations) > - Cherry pick patch > - Merge changes into all derived featuresets, if any Rather than rebasing? > - Record new top commits and update changelog in main repo So that's two commits rather than one at present. A little annoying. > There are some things not yet implemented or different in my preview: > - debuild from the repo tree does not yet work, the rules are missing > the special directory definitions > - orig is also a submodule > > Please take a look and let me know what you think about this variant. > Most likely I've forgotten something, but I don't know what it is. What I like: 1. Rebasing is easier 2. I can log, diff, etc. through our changes and upstream changes What I don't like: 3. Pushing is more complicated 4. Cherry-picking is more complicated 5. Git working directory looks different from unpacked source package 6. It's not possible to see the history of one of our patches (3) and (4) definitely need to be addressed, either by documentation (if I'm missing some git feature or config) or by scripting. I think I can live with (5) and (6). For (6), maybe we should start putting Change-Ids in our changes so that it would be possible to find all versions using 'git log --tags=debian --grep=...' Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody.
signature.asc
Description: This is a digitally signed message part