On Sat, 2015-11-07 at 17:49 +0100, Bastian Blank wrote: [...] > > 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)? > > I think we have to tag while updating. We would need to rebase the > already published branches, if we change the orig later. Also it is > impossible to build a source package without the tag. OK. > > > - 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? > > Sure, thats support infrastructure. > > > The submodules are checked out with detached heads by default. Is your > > intent that we would override this? > > Do you know if we can change it? No, as I said I'm not familiar with submodules. > > I tried this: > > $ cd source/orig > > source/orig is supposed to go away. At least that was my plan. > > > Is it possible to combine those push commands? Is this something else > > we would need to script? > > It is possible to change the way push works via the config, you can > specify what is going to be pushed. Including sub-modules? From what you wrote below, it sounds like that isn't possible. > > > - 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? > > Rebasing published branches is no nice thing to do. OK, I suppose this is different from rebasing onto a new upstream as there we're creating a new branch. So in case we want to drop a patch, presumably we would revert the commit and then drop both the original and revert when moving to a new upstream? > > What I don't like: > > 3. Pushing is more complicated > > git push can push all submodules as well, but I don't see a config > option for it. I should use the option --recurse-submodules=on-demand, right? In the absence of a configuration variable, it would presumably be sensible to recommend an alias for this e.g. 'push-sm = push --recurse-submodules=on-demand' > > 4. Cherry-picking is more complicated > > Yeah. That warrants a script. > > > 6. It's not possible to see the history of one of our patches > > Which history do you mean? Currently we can run 'git log debian/patches/a/random.patch' and see when a patch was originally added and how it changed as it was rebased onto different upstream versions. If we were to use a merge-based workflow then 'git log <upstream>.. patched/file.c' would provide similar information. But with a rebasing workflow, the git object model doesn't provide any association between the commits that apply a patch onto different upstream versions. Ben. -- Ben Hutchings 73.46% of all statistics are made up.
Attachment:
signature.asc
Description: This is a digitally signed message part