Felipe Sateler writes ("Re: dgit: can't handle debian branch with removed
files"):
> On Wed, Jun 21, 2017 at 10:27 AM, Ian Jackson
> <[email protected]> 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.
