Merging upstream git history into the debian packaging history?

[Felipe Sateler]

On Thu, Aug 29, 2013 at 6:06 AM, Jonas Smedegaard <dr at jones.dk> wrote:
> Quoting Felipe Sateler (2013-08-28 23:31:57)
>> 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?
>
> By your premise, "patches" can mean an interaction with a git
> repository.
>
> I do not accept your premise, and my "patches" above implies flat files.
>
> Does that help resolve your confusion?

Partly. The point is that I understand patches as a way of
communicating with upstream. If upstream uses git (a premise for the
current discussion to make sense), git branches/commits seem to me a
better communication strategy than patches as flat files. I presume
you value flat files for other reasons?

>
> I am a big fan of git.  But others are fan of other VCSes, and some
> still haven't seen (any of) the light(s).  So I see a relevancy of a
> "middle ground" using flat files and tarballs.

But we are talking about integrating upstream and debian VCS, which
means we are all using git.

>
> I have recently been made aware of gbp-pq, which sounds like the right
> tool to me: juggle patches as git branches, but flatten sensibly (not a
> single huge chunk!) when "exporting" to the files-and-tarballs World.
> Haven't explored it yet, though - perhaps that would be interesting to
> you too?

I tried it once, and didn't really like it. However, gbp-pq does not
juggle patches as git branches. Rather, it applies the patch series as
*one* git branch. You can then rebase and reorder it as you see fit,
and gbp-pq will then recreate the quilt patch series. An improvement
over plain quilt, but not sure if really useful (plus, you lose the
Nxxx naming convention, which I've grown accostumed to).

-- 

Saludos,
Felipe Sateler