[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: git vs dfsg tarballs

Enrico Weigelt, metux IT consult writes ("Re: git vs dfsg tarballs"):
> On 19.11.18 13:52, Ian Jackson wrote:
> > I think that most of the workflows recommended in these manpages
> > 
> >   https://manpages.debian.org/stretch-backports/dgit/dgit-maint-gbp.7.en.html
> >   https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html
> >   https://manpages.debian.org/stretch-backports/dgit/dgit-maint-debrebase.7.en.html
> Yet complicated for me (especially regarding automating/CI).

I'm sorry, I think you have misunderstood my point.  I wasn't
suggesting that *you* should follow the recommendations in those

I am saying that for packages whose Debian maintainer follow those
recommendations, much of what you want would be straightforward - or,
anyway a lot easier.  So I was plugging my recommendations.

I was also inviting comment from you as a downstream, if there are
ways recommendations (and tools such as dgit) could be improved.

> Here're some examples on how my deb branches look like:

Not sure what you mean by `your deb branches', but looking at what
Debian gives you:

> * canonical ref names

dgit (dgit clone, dgit fetch) will give you this, regardless of the
maintainer's behaviour.

> * always based on the corresponding upstream's release tag

A maintainer who uses dgit and follows the recommendations in the
dgit-maint-*(7) manpages will give you this.

So I think you should be plugging dgit to maintainers, like I am :-).

> * changes directly as git commits - no text-based patches whatsoever

dgit will pretty much give you this, regardless of the maintainer's
behavior, because it will automatically convert the `text based
patches' into git commits so the git commits are there.

> * generic changes below the deb-specific ones

Again, dgit will give you this.

> 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.

One of dgit's objectives is to make the work of downstreams easier.


Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply to: