Hi Sean, Hi Loong Jin, On Mon, Feb 28, 2011 at 12:30:15AM +0100, Sean Finney wrote: > Hi, > > Chiming in here as I'm finding myself in the situation of needing to use > submodules for one of my packages due to upstream... decisions.... > > I took a look over Loong Jin's patches, and in the default case they > seem to work, which is awesome! I've rebased them to master, and fixed > a regression that floated up in the meantime with the packaging > self-tests and the new code:
Thanks to both of you for the work in this! > > http://git.debian.org/?p=users/seanius/git-buildpackage.git > > I'm a bit concerned about the muckery with the working tree though. > > I'm not sure that stashing and branch switching is really the right way > to go here. Really I'm not sure that we should be messing with the > working tree at all (maybe just fail regardless if the working tree is > dirty, since orig.tar.gz creation is kinda important). but if gbp is > already doing that internally (is it?) maybe it's not such a problem. We're not using stash at all at the momment and try to avoid branch switching. In order to do so we use git-read-tree and git-write-tree used at other places. If I read the code correctly the stash is needed to make sure we have a clean tree before switching to upstream to update the submodules? Since the update of the submodules is a fast forward I wonder if we can't update them without the switch? Also we do we update the submodules at all before exporting them? Can't we assume they're up to date and simply add their contents to the tarball? We don't update the upstream branch either. Cheers, -- Guido > but anyway, specifically with stash, it can only handle files already > staged. If you have files changed but not staged, then stash will miss > them, and later stash will fail to to pop, causing gbp to abort. > > So if you're going the stash route, i think you'll need to change it to > do the following: > > at archive time: > > * if the tree is dirty, stash with a pre-determined message stash1 > * if the tree is still dirty, (unstaged) git add . && stash with stash2 > > at pop time: > > * check for both stash1 and stash2, and only try to pop them if found > > > does that make sense? what do you think? In the meantime, I'll > continue using Loong Jin's patches and just pay closer attention when it> > comes to building the tarballs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
