Quoting Ian Jackson (2017-01-29 00:56:09)
> Johannes Schauer writes ("Bug#852940: dgit: Feature or doc of workflow that
> allows one to repeatedly amend patches in 3.0 (quilt)"):
> > I now found myself with 17 individual patches in debian/patches and
> > thought it was time to report this bug asking for help.
>
> How annoying.
>
> Yes, this is a problem. Right now there is no very good answer for
> using Debian `3.0 (quiilt)' packages with raw git (which is
> effectively what you are trying to do). The fact that this is hard is
> why we have tools like git-dpm and gbp (which maintain their own
> not-very-raw-git-like views of the world - so I don't really consider
> them good answers).
>
> You have several options but none of them are particularly good:
>
> * Manually strip the dgit-generated debian/patches-commits with
> git-reset, or git-rebase, or something, after each build;
>
> * Use a second git tree, and
> 1st-tree$ git push ../2nd-tree +HEAD:t
> 2nd-tree$ git checkout t~0 && dgit -wgf sbuild
> so that the dgit-generated commit does not end up on your own
> HEAD. (You could make the 2nd tree a git-worktree of the 1st,
> and then you would not need the `git push'.)
>
> * Switch to using gbp or git-dpm (which have quite different
> workflows and have perhaps solved this problem.
>
> * Switch to source format 1.0 (with or without diff). Then there are
> no autogenerated commits because the diff is entirely out-of-tree.
> Of course that means that ony dgit users see the patch stack.
> (If your tree package isn't representable by 1.0-with-diff, you
> will also need to go back in time 12 months and answer my RFH for
> sorting out my proposed `3.0 (rsync)' source format...)
>
> Right now I am working on a rebase tool that will help with some of
> these things. You will be able to say `git-debrebase' and it will
> DTRT. The autogenerated patches will automatically evaporate.
>
> Alternatively, it would be possible in principle for dgit to support a
> split brain version of the existing non-split-brain quilt modes. That
> would have the same effect as the 2nd option above. I'm not sure this
> is a very good idea.
>
> > Currently, once I'm happy with my changes I would do "git rebase -i" to
> > remove all the dgit-created commits and squash my other commits into a
> > single one. With 17 different commits this becomes tedious...
>
> Yes. You may be able to make an ad-hoc rune to filter them.okay, I understand that I wasn't missing any existing way to solve or prevent this other than moving from 3.0 (quilt) to another workflow. Thanks a lot for all your input! It's now up to you whether you want to keep this bug open with anything you want to improve or fix or close it. cheers, josch
signature.asc
Description: signature
