Re: Feedback on 3.0 source format problems
On Jan 03 2017, Sean Whitton <email@example.com> wrote:
> On Tue, Jan 03, 2017 at 10:39:33AM -0800, Nikolaus Rath wrote:
>> > git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'
>> Yes, but that's not as useful as what git-debcherry produces.
>> For example, if you get a merge conflict when rebasing, the above
>> incantation will list two commits: the original debian commit and the
>> merge commit. git-debcherry, on the other hand, will synthesize one
>> patch, consisting of the original Debian commit, but modified to include
>> the *relevant parts* of the merge commit.
> That's a good point. In this context, `git debcherry` is a tool to
> filter and neaten a git history. However, it inserts another step
> between upstream, and powerful tools like git-cherry-pick and
> git-bisect. Upstream now has to know that Debian has orig.tars and
> various ways of representing changes to them.
> If I were a busy upstream, I would much rather `git fetch` my Debian
> maintainer's branches, and then immediately set to work cherry-picking
> and bisecting. I don't need any Debian-specific knowledge, except that
> which is relevant to the bug I'm trying to fix -- I don't need to know
> what an orig.tar is. This is worth having to look at a few merge
Are there really upstreams that do that? I'd expect that the primary
consumer of Debian patches are other distributions, downstreams, and
I'd think that anything that's relevant for upstream development is
forwarded to upstream by the maintainer in whatever format upstream
prefers. This requires extra time, but I would be surprised to hear if
there are maintainers that have sufficient time to create patches that
are suitable for upstream, but don't have the little extra time to send
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«