Felipe Sateler writes ("Re: dgit: can't handle debian branch with removed files"): > On Wed, Jun 21, 2017 at 10:27 AM, Ian Jackson > <ijack...@chiark.greenend.org.uk> wrote: > > 3. You could add a quilt patch which deletes them.
I forgot to ask: do you know if this is easy to do with gbp ? > > 4. dgit could automatically generate a quilt patch which deletes them > > and include it only in the dgit view. ... > There is another option: > > 5. dgit mimics dpkg-source and ignores deletions and thus adds the files > back in the dgit view. Indeed. I don't think this is a good idea, though. Clearly the files aren't needed for building (since the uploader will be using a gbp branch why doesn't contain them). Sometimes files are deleted in this way because they are deleted by rules clean, and that is done because the build creates and/or updates them. In that situation having them committed to git is a nuisance: the dgit downstream user has to git reset --hard after each build, and their diffs are full of noise. Better to have them deleted. Then if they get recreated, they show up as untracked files and a downstream user's git-clean will delete them again. > > What is your opinion about the relative merits of you adding the > > patch, in your own gbp branch, vs dgit "secretly" adding the deletion > > patch in the dgit view ? > > Honestly, I'm not sure. In this case, dgit caught a real problem with > the repository. On other cases, it would be desirable to have dgit > perform step (5), so it mimics what dpkg-source does. I don't think > doing (4) is sane, because in effect that would mean that builds from > dgit are different from builds done by sbuild or pbuilder. Perhaps whether to have dgit fix it up on the dgit branch should be a config option, or a variant on the gbp quilt mode ? --quilt=gbp --include-removal --quilt=gbp-rm Of course we already do what amounts to --include-removal in non-split-brain mode. But that's much less sneaky. Thanks BTW for this useful discussion. Ian.