Re: git vs dfsg tarballs
On 19.11.18 13:52, Ian Jackson wrote:
> Clearly the transformation on the *tree* can't be reversible because
> in the usual case it is deleting things. So you'll need the history.
It certain can be, if you know the exact orig commit.
Maybe I wasn't really clear here: I wanna do a fully automatic import
into a git history (optimally, by just having package name and version).
> With most gitish workflows, the corresponding pre-dfsg upstream
> *commit* can be found with `git-merge-base', assuming you have some
> uploaded (or pushed) Debian commit and a suitable upstream branch.
It's not entirely trivial, if the maintainers are doing wild merges.
(eg. w/ kodi). Even worse: reconstructing the change history ontop
of some given upstream release is pretty complicated and manual.
Merging down from upstream into packaging branch (instead of just
a simple rebase) turns out as bad idea here.
>> My preferred way (except for rare cases where upstream history is
>> extremely huge - like mozilla stuff) would be just branching at the
>> upstream's release tag and adding commits for removing the non-dfsg
>> files ontop of that. From that branching the debianized branch,
>> where all patches are directly applied in git.
> I think that most of the workflows recommended in these manpages
Yet complicated for me (especially regarding automating/CI).
Here're some examples on how my deb branches look like:
* canonical ref names
* always based on the corresponding upstream's release tag
* changes directly as git commits - no text-based patches whatsoever
* generic changes below the deb-specific ones
While gbp can help a bit here and there, it still far away from an
I'm currently helping myself w/ lots of mappings and import scripts,
but I'd like to get rid of maintaining all these little pieces.
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
firstname.lastname@example.org -- +49-151-27565287