Converting the git archive to a more "mainstream" layout

[Andreas Metzler]

On 2024-12-07 Marc Haber <mh+debian-packages at zugschlus.de> wrote:
> On Sat, Dec 07, 2024 at 07:56:19AM +0100, Andreas Metzler wrote:
> > Not to mince words: I have a very very very strong preference for
> > keeping a debian-only layout.

> Okay, I'll then ditch all my efforts.

> While we're at it, I haven't contributed in probably more than a decade.
> If you haven't removed me yet, this would probably be a good time to do
> so. Especially since I haven't been able to build exim packages in many
> years due to the debian-only layout that doesn't work all well for me
> with the newer tools.

Hello,

well I am (kind of forced to) use git-buildpackage for other packages
both with upstream simply containing imported tarballs and the platinum
issue with merged upstream git repo and it mainly gets in my way without
the corresponding payoff. I am /maintaining/ a package not doing upstream
coding and gpb with orig makes this very complicated. It feels like
stuffing a cow and a dog into a box and hoping for souffle.

Just to illustrate, if I wanted to help along somebody else and prepare
the packaging for a new upstream release including all the grunt work…
* With debian-only I simply fork the repo, prepare the packaging and can
  pass this on either as a merge request or a patch-series which
  $maintainer can git am or merge.
* With an integrated repo I need to fork all three branches
  (upstream/pristine-tar and the working one), do the work and send a
  explaining email to the maintainer. ("Take this repo as an additional
  upstream and manually ff-merge all three branches.")

Another example is when one temporarily branches off for uploading a
beta version to experimental for a couple of months. With debian-only I
can keep the packaging up to date by making the changes on the stable
branch and simply merging it to experimental. This still works if there
is a minor release on the stable branch. And it ends happliy and cleanly
with a -ff-only merge of experimental to stable. OTOH with the
integrated repo ones needs to also split-off another upstream branch and
cherry-pick[1] debian-specific changes to experimental and hope none are
missed and it ends with a false merge, overwriting stable with
experimental (merge strategy ours).

I do know that I am alone in not being happy with regular gbp, Guillem
has a stated preference for debian-only and KDE uses it, too. The git
savy people also often use something else. But for me debian-only
really seems the best way, it is also what basically everybody but Debian
uses.

FWIW
gbp buildpackage --git-tarball-dir=/path/to/tarballs --git-export-dir=..
works with the current exim repo.

> Thanks for all the fish, and I am sure that you will continue to do
> superb work on exim in the future.
[...]

I am really sorry to see you go. Thank you, I think we used to make a
good team.

cu Andreas

[1] I am sure there is some git-foo to automatize this but
cherry-picking is still going to be essentially what happens.