Merging upstream git history into the debian packaging history?

[Felipe Sateler]

On Sun, Aug 25, 2013 at 6:37 PM, Jonas Smedegaard <dr at jones.dk> wrote:
>
> Quoting Felipe Sateler (2013-08-26 00:09:49)
> > On Sat, Aug 24, 2013 at 2:33 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> > > Quoting Felipe Sateler (2013-08-24 18:59:03)

> > >> 2. Managing patches: it looks to me like the new workflow makes it
> > >> better to make changes directly to the sources (by cherry-picking
> > >> the appropriate commits/ merging the appropriate debian-specific
> > >> branches) and setting single-debian-patch in local-options. Has
> > >> anyone tried this?
> > >
> > > I still favor quilt patches - and don't follow how tying our git to
> > > upstream git renders that inferior: I consider it two separate
> > > Worlds - one using git and another using tarballs and patch files.
> >
> > I guess I see the main benefit of the new workflow precisely that the
> > separate worlds become one. Taking a patch from upstream is as simple
> > as a cherry-pick, forwarding a patch becomes a pull request of a topic
> > branch (or committing directly, if one is also part of upstream). My
> > take is that seeing the debian package as a slightly edited branch of
> > upstream makes a lot of sense.
> >
> > If you accept the above premise, then the single-debian-patch option
> > seems very useful (applied in local-options, so that NMUs don't
> > break).
>
> Ok.  We then do not value tarballs and patches the same.

I'm confused. Tarballs are preserved, and patches are still available,
although at the git repository. AFAICS, there is no data loss in the
mechanism I'm describing, am I wrong?


-- 

Saludos,
Felipe Sateler