Preferred git branch structure when upstream moves from tarballs to git

classic Classic list List threaded Threaded
87 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Preferred git branch structure when upstream moves from tarballs to git

Gard Spreemann-2
Hi,

For one of my packages, I maintain two public git branches: one is
upstream/latest, where I've been importing upstream's released tarballs,
and the other is debian/sid that contains the packaging.

Recently, upstream has finally started using git. What is the
recommended way for me to maintain a sane branch structure for the
packaging repository while starting to use upstream's git master as the
upstream branch to follow?

(My first thought is to track upstream's master as upstream/latest-git
or something, and start merging from that into debian/sid, but I don't
know if there's a better way.)


 Best,
 Gard

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Adam Borowski-3
On Mon, Apr 29, 2019 at 11:18:48AM +0200, Gard Spreemann wrote:

> For one of my packages, I maintain two public git branches: one is
> upstream/latest, where I've been importing upstream's released tarballs,
> and the other is debian/sid that contains the packaging.
>
> Recently, upstream has finally started using git. What is the
> recommended way for me to maintain a sane branch structure for the
> packaging repository while starting to use upstream's git master as the
> upstream branch to follow?
>
> (My first thought is to track upstream's master as upstream/latest-git
> or something, and start merging from that into debian/sid, but I don't
> know if there's a better way.)

Naming doesn't really matter -- automated tools know only about the
packaging branch, and that's specified in the Vcs-Git field.

So it's mostly about workflow.  Here the opinions differ greatly, and it's a
fine area for flamewars.  There are those who swear by gbp, while for me
that's a monstrosity -- my personal preference is raw git, where updating to
a new upstream is "git merge v3.14.15", with all git goodness like
cherry-pick or bisect working unmolested.  But workflow choices are many.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Andrey Rahmatullin-3
On Mon, Apr 29, 2019 at 11:40:39AM +0200, Adam Borowski wrote:
> that's a monstrosity -- my personal preference is raw git, where updating to
> a new upstream is "git merge v3.14.15"
gbp allows this too, of course.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Andrey Rahmatullin-3
In reply to this post by Gard Spreemann-2
On Mon, Apr 29, 2019 at 11:18:48AM +0200, Gard Spreemann wrote:

> For one of my packages, I maintain two public git branches: one is
> upstream/latest, where I've been importing upstream's released tarballs,
> and the other is debian/sid that contains the packaging.
>
> Recently, upstream has finally started using git. What is the
> recommended way for me to maintain a sane branch structure for the
> packaging repository while starting to use upstream's git master as the
> upstream branch to follow?
>
> (My first thought is to track upstream's master as upstream/latest-git
> or something, and start merging from that into debian/sid, but I don't
> know if there's a better way.)
It's hard to answer not knowing your workflows, for example how are you
using those branches and how do you create the orig tarball.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Ian Jackson-2
In reply to this post by Gard Spreemann-2
Gard Spreemann writes ("Preferred git branch structure when upstream moves from tarballs to git"):
> Recently, upstream has finally started using git. What is the
> recommended way for me to maintain a sane branch structure for the
> packaging repository while starting to use upstream's git master as the
> upstream branch to follow?

The dgit workflow manpages present a smorgasbord of possibilities to
choose from.  (You can use much of this without dgit, but of course
everyone should be using dgit.)

Look at the intro to each of these and see which one you think might
be best:
 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
 https://manpages.debian.org/stretch-backports/dgit/dgit-maint-gbp.7.en.html
 https://manpages.debian.org/stretch-backports/dgit/dgit-maint-native.7.en.html

Adam mentioned gbp-pq, which is discussed in dgit-maint-gbp(7), and
using plain `git merge', which is discussed in dgit-maint-merge(7).

The dgit-maint-merge(7) manpage intro is particularly good at helping
select a workflow.

dgit-maint-debrebase uses my new git-debrebase tool which you may find
easier than gbp pq.

Ian.

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Ian Campbell-5
On Mon, 2019-04-29 at 13:25 +0100, Ian Jackson wrote:
> Look at the intro to each of these and see which one you think might
> be best:
>  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
>  https://manpages.debian.org/stretch-backports/dgit/dgit-maint-gbp.7.en.html
>  https://manpages.debian.org/stretch-backports/dgit/dgit-maint-native.7.en.html

Are there any docs/advice on switching back and forth between these (or
at least switching between dgit-maint-merge and one of the patch
queueish ones)?

When trying to chose I seem to find myself thinking along the lines
"merge would be fine right now, but whatif..." or "I have a big queue
now which isn't going anyway but I really hope it will go away
(eventually)".

I'm not thinking anyone would flip regularly or anything, but just
knowing that flipping between them in something approaching a sane way
was possible at all would give some confidence to make a choice in the
here and now without getting too paralysed by the need to make a
decision.

I think (but don't know) that the answer is that if your queue drops to
zero you have effectively flipped back to the dgit-maint-merge world.
If you find you want to go the other way then I'm less clear (except
perhaps that is `git debrebase convert-from-dgit-view` and then commit
to non-debian/ as usual?).

Ian.

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Russ Allbery-2
In reply to this post by Gard Spreemann-2
Gard Spreemann <[hidden email]> writes:

> For one of my packages, I maintain two public git branches: one is
> upstream/latest, where I've been importing upstream's released tarballs,
> and the other is debian/sid that contains the packaging.

> Recently, upstream has finally started using git. What is the
> recommended way for me to maintain a sane branch structure for the
> packaging repository while starting to use upstream's git master as the
> upstream branch to follow?

A lot of people have told you that you have a lot of options, which is of
course true.  But in case you're looking for an opinionated answer rather
than a range of options: in cases like this, I track the upstream master
branch in my repository as master, just as if I had a regular clone of
upstream, and use debian/master (or debian/sid if you want) for the
packaging.

I experimented with a few other approaches, and this one seemed to cause
the least amount of pain.  It means I'm not renaming the upstream branches
when I pull them into my repository (which is possible to do in Git but
tedious and irritating if you get the .git/config runes incorrect or some
tool doesn't pay attention and merges the wrong branch).

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Sean Whitton
In reply to this post by Gard Spreemann-2
Hello,

On Mon 29 Apr 2019 at 11:18AM +02, Gard Spreemann wrote:

> For one of my packages, I maintain two public git branches: one is
> upstream/latest, where I've been importing upstream's released tarballs,
> and the other is debian/sid that contains the packaging.
>
> Recently, upstream has finally started using git. What is the
> recommended way for me to maintain a sane branch structure for the
> packaging repository while starting to use upstream's git master as the
> upstream branch to follow?

An simple approach is to use 'master' for packaging and *not* maintain
upstream branches in your repository.  Instead, you fetch upstream's
release tags and merge those.

Quoting from dgit-maint-debrebase(7), though the point is more widely
applicable than that workflow:

       The idea here is that from Debian's point of view, upstream
       releases are immutable points in history.  We want to make sure
       that we are basing our Debian package on a properly identified
       upstream version, rather than some arbitrary commit on some
       branch.  Tags are more useful for this.

       Upstream's branches remain available as the git remote tracking
       branches for your upstream remote, e.g. remotes/upstream/master.

The reason for not *additionally* maintaining upstream branches is
simply that then you don't have to keep track of whether they are
up-to-date.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Sean Whitton
In reply to this post by Ian Campbell-5
Hello,

On Mon 29 Apr 2019 at 02:12PM +01, Ian Campbell wrote:

> Are there any docs/advice on switching back and forth between these (or
> at least switching between dgit-maint-merge and one of the patch
> queueish ones)?
>
> When trying to chose I seem to find myself thinking along the lines
> "merge would be fine right now, but whatif..." or "I have a big queue
> now which isn't going anyway but I really hope it will go away
> (eventually)".
>
> I'm not thinking anyone would flip regularly or anything, but just
> knowing that flipping between them in something approaching a sane way
> was possible at all would give some confidence to make a choice in the
> here and now without getting too paralysed by the need to make a
> decision.
>
> I think (but don't know) that the answer is that if your queue drops to
> zero you have effectively flipped back to the dgit-maint-merge world.
> If you find you want to go the other way then I'm less clear (except
> perhaps that is `git debrebase convert-from-dgit-view` and then commit
> to non-debian/ as usual?).
dgit-maint-merge -> dgit-maint-debrebase would indeed be the
convert-from-dgit-view subcommand.  If I were dealing with this, for
simplicity, I would start from the point of just having made an upload.
That way you know your HEAD is a valid dgit view.

dgit-maint-debrebase -> dgit-maint-merge would be simply to stop using
the `git debrebase` tool.

dgit-maint-debrebase -> dgit-maint-merge -> dgit-maint-debrebase might
get tricky, because `git debrebase` might get confused by your git
history.  I think, though, that any problems would count as bugs in the
convert-from-dgit-view subcommand.

Switching between dgit-maint-gbp and either -merge or -debrebase is
tricky because you are going from patches-unapplied to patches-applied.
What I think you would want to do is use convert-from-gbp, and then if
you wanted -merge, just don't invoke `git debrebase` anymore.  But I am
not sure.

Do you think it would be helpful to add sections to both the -merge and
-debrebase manpages saying this stuff?

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Ben Finney-3
In reply to this post by Gard Spreemann-2
Gard Spreemann <[hidden email]> writes:

> Recently, upstream has finally started using git. What is the
> recommended way for me to maintain a sane branch structure for the
> packaging repository while starting to use upstream's git master as
> the upstream branch to follow?

My opinionated recommendation: Track the Debian packaging in a separate
repository (which contains only the ‘debian/’ directory tree). When it's
time to build the Debian source package for testing, export the upstream
source to a temporary build directory and export the Debian packaging
onto that. Build the Debian source package from the result.

(Of course, Git-BuildPackage supports this workflow, with the ‘--export’
and related options.)

Insulation from the kind of changes in upstream publishing that you
describe, is a significant advantage of this Debian packaging workflow.

--
 \         “My girlfriend has a queen sized bed; I have a court jester |
  `\   sized bed. It's red and green and has bells on it, and the ends |
_o__)                                         curl up.” —Steven Wright |
Ben Finney

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Paul Wise via nm
On Tue, Apr 30, 2019 at 9:03 AM Ben Finney wrote:

> My opinionated recommendation: Track the Debian packaging in a separate
> repository (which contains only the ‘debian/’ directory tree). When it's
> time to build the Debian source package for testing, export the upstream
> source to a temporary build directory and export the Debian packaging
> onto that. Build the Debian source package from the result.

I like this option because it still works well if we ever decide to
fix a fundamental flaw in the Debian source package layout. The
directory hierarchy we use is inverted from one that would be logical
based on the relationship between the components of the Debian source
package. The Debian packaging (especially debian/rules) wraps and
controls the interaction of the Debian tools with the upstream source
but the debian/ directory is located inside the upstream source
instead of the upstream source being a subdirectory of the Debian
packaging.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Russell Stuart
On Tue, 2019-04-30 at 09:25 +0800, Paul Wise wrote:
> I like this option because it still works well if we ever decide to
> fix a fundamental flaw in the Debian source package layout.

I suspect whether that's a fundamentally is a matter or personal taste.
 On this point my taste aligns with yours.

I've used both rpm source format and the Debian one, and IMO the rpm
one is mostly better.  The primary reason is the one you've mention
here: they maintain the separation between the source, rpm spec, and
build areas's far more cleanly than Debian does.  This makes some
common flaws one often flaws in Debian packages just disappear: like
cleaning up the source directory after a build.

Where the rpm format goes wrong is it then beaks that separation in the
actually .srpm format by putting the upstream source in and rpm bits in
one file, which is of course what Debian gets right.  Sigh.

On the positive side, rpm and deb seem to be gradually converging in a
sort of co-evolution.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Ansgar Burchardt-8
Russell Stuart writes:

> On Tue, 2019-04-30 at 09:25 +0800, Paul Wise wrote:
>> I like this option because it still works well if we ever decide to
>> fix a fundamental flaw in the Debian source package layout.
>
> I suspect whether that's a fundamentally is a matter or personal taste.
>  On this point my taste aligns with yours.
>
> I've used both rpm source format and the Debian one, and IMO the rpm
> one is mostly better.  The primary reason is the one you've mention
> here: they maintain the separation between the source, rpm spec, and
> build areas's far more cleanly than Debian does.  This makes some
> common flaws one often flaws in Debian packages just disappear: like
> cleaning up the source directory after a build.

I also agree with this.  It is also not only RPM, but for example also
Gentoo, Arch and others which contain only the distro-specific parts in
their repositories.

This also makes things easier as developers do not have to know about
branch management, merging, rebasing, ... to start with.  Many people
using Git don't know how to do this.

As an example: to update to a new upstream release, I ideally just have
to drop the new upstream tarball, update d/changelog and am done.
Compare with [1] which is much more complicated, even ignoring the extra
complexity using dgit adds compared to just using git.

Ansgar

  [1] https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html#NEW_UPSTREAM_RELEASES

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Thomas Goirand-3
In reply to this post by Gard Spreemann-2
On 4/29/19 11:18 AM, Gard Spreemann wrote:

> Hi,
>
> For one of my packages, I maintain two public git branches: one is
> upstream/latest, where I've been importing upstream's released tarballs,
> and the other is debian/sid that contains the packaging.
>
> Recently, upstream has finally started using git. What is the
> recommended way for me to maintain a sane branch structure for the
> packaging repository while starting to use upstream's git master as the
> upstream branch to follow?
>
> (My first thought is to track upstream's master as upstream/latest-git
> or something, and start merging from that into debian/sid, but I don't
> know if there's a better way.)
>
>
>  Best,
>  Gard

What I found the most easy way is to just use whatever branching names
upstream is using, and *never* store them in Salsa. If you need upstream
repository, you can simply run a ./debian/rules fetch-upstream-remote,
and most of the time, the only thing you need, is merging a tag. What I
push to Salsa are upstream tags only, which is enough.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Adam Borowski-3
On Tue, Apr 30, 2019 at 09:04:09AM +0200, Thomas Goirand wrote:
> What I found the most easy way is to just use whatever branching names
> upstream is using, and *never* store them in Salsa. If you need upstream
> repository, you can simply run a ./debian/rules fetch-upstream-remote,
> and most of the time, the only thing you need, is merging a tag. What I
> push to Salsa are upstream tags only, which is enough.

Why?  I strongly disagree: having the upstream tree in the same repo
as packaging is awesome.  It lets you mix patches both ways with no effort.
Having the upstream tree at home but not pushing it deprives contributors
who are not you of this comfort.

As all the data is already in the repo, having it available as a branch
and tags doesn't cost any non-metadata space.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Ian Campbell-5
In reply to this post by Sean Whitton
On Mon, 2019-04-29 at 13:50 -0700, Sean Whitton wrote:

>
> dgit-maint-merge -> dgit-maint-debrebase would indeed be the
> convert-from-dgit-view subcommand.  If I were dealing with this, for
> simplicity, I would start from the point of just having made an upload.
> That way you know your HEAD is a valid dgit view.
>
> dgit-maint-debrebase -> dgit-maint-merge would be simply to stop using
> the `git debrebase` tool.
>
> dgit-maint-debrebase -> dgit-maint-merge -> dgit-maint-debrebase might
> get tricky, because `git debrebase` might get confused by your git
> history.  I think, though, that any problems would count as bugs in the
> convert-from-dgit-view subcommand.

Excellent, thanks for confirming/explaining.

> Switching between dgit-maint-gbp and either -merge or -debrebase is
> tricky because you are going from patches-unapplied to patches-applied.
> What I think you would want to do is use convert-from-gbp, and then if
> you wanted -merge, just don't invoke `git debrebase` anymore.  But I am
> not sure.

Yes, I can see how that case is more complex. I think for me at least
that would mean I would simply prefer debrebase anyway so being able to
cycle via gbp wouldn't worry me too much.

> Do you think it would be helpful to add sections to both the -merge and
> -debrebase manpages saying this stuff?

I do, yes, it would knock a potential mental rathole (at least for
me...) out of the picture.

Ian.

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Ian Jackson-2
In reply to this post by Sean Whitton
Sean Whitton writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"):
> On Mon 29 Apr 2019 at 02:12PM +01, Ian Campbell wrote:
> > Are there any docs/advice on switching back and forth between these (or
> > at least switching between dgit-maint-merge and one of the patch
> > queueish ones)?
...
> > I'm not thinking anyone would flip regularly or anything, but just
> > knowing that flipping between them in something approaching a sane way
> > was possible at all would give some confidence to make a choice in the
> > here and now without getting too paralysed by the need to make a
> > decision.

That makes a lot of sense.

> > I think (but don't know) that the answer is that if your queue drops to
> > zero you have effectively flipped back to the dgit-maint-merge world.
> > If you find you want to go the other way then I'm less clear (except
> > perhaps that is `git debrebase convert-from-dgit-view` and then commit
> > to non-debian/ as usual?).

When your queue is empty, dgit-maint-merge and dgit-maint-gbp are
equivalent and dgit-maint-debrebase is "very close".

When you go from git-merge to separated-patches, you have to create
the additional information: the split of the delta into separate
patches with commit messages.  However, I guess as the user you have
already figured that out and what you want is to know that you can
turn git-merge into
  separated-patches but currently with one patch with
    an autogenerated commit message
and then you would use normal git-fu to rework that into the desired
pretty patch series.

> Do you think it would be helpful to add sections to both the -merge and
> -debrebase manpages saying this stuff?

I think we should have a separate manpage.  This kind of conversion
stuff is (hopefully) used rarely.

Ian.

--
Ian Jackson <[hidden email]>   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 | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Ian Campbell-5
On Tue, 2019-04-30 at 12:05 +0100, Ian Jackson wrote:

> Sean Whitton writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"):
> > On Mon 29 Apr 2019 at 02:12PM +01, Ian Campbell wrote:
> > >
> > > I think (but don't know) that the answer is that if your queue drops to
> > > zero you have effectively flipped back to the dgit-maint-merge world.
> > > If you find you want to go the other way then I'm less clear (except
> > > perhaps that is `git debrebase convert-from-dgit-view` and then commit
> > > to non-debian/ as usual?).
>
> When your queue is empty, dgit-maint-merge and dgit-maint-gbp are
> equivalent and dgit-maint-debrebase is "very close".
>
> When you go from git-merge to separated-patches, you have to create
> the additional information: the split of the delta into separate
> patches with commit messages.  However, I guess as the user you have
> already figured that out and what you want is to know that you can
> turn git-merge into
>   separated-patches but currently with one patch with
>     an autogenerated commit message
> and then you would use normal git-fu to rework that into the desired
> pretty patch series.

Ack, yes.

> > Do you think it would be helpful to add sections to both the -merge and
> > -debrebase manpages saying this stuff?
>
> I think we should have a separate manpage.  This kind of conversion
> stuff is (hopefully) used rarely.

Assuming some x-refs from the relevant places that seems perfectly
sensible too me.

Ian.

Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Sean Whitton
In reply to this post by Ansgar Burchardt-8
Hello,

On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote:

> As an example: to update to a new upstream release, I ideally just have
> to drop the new upstream tarball, update d/changelog and am done.
> Compare with [1] which is much more complicated, even ignoring the extra
> complexity using dgit adds compared to just using git.
>
>   [1] https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html#NEW_UPSTREAM_RELEASES

As a package maintainer, if you don't keep the whole source package in
git, you're giving up on a lot of the power of git.  The most
significant thing is that you cannot manipulate quilt patches as commits
on a branch.  It is also much more involved to cherry pick commits from
upstream branches, and quickly obtain diffs between Debian's version of
the code and arbitrary other branches, to mention a few other things.

I also think that you're doing a disservice to downstream users.  If
you're trying to fix a bug in the packaged version of some software on
your computer, you don't care about the distinction between Debian's
packaging scripts and the upstream code.  It's all going to be turned
into a .deb once you've fixed your problem.  You want the history of the
whole thing.  Thus, a git history that contains both the upstream git
history and the Debian maintainer's changes to the packaging scripts is
going to be very useful.  A git history of only the Debian packaging
scripts is much less useful.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Preferred git branch structure when upstream moves from tarballs to git

Thomas Goirand-3
In reply to this post by Adam Borowski-3
On 4/30/19 9:55 AM, Adam Borowski wrote:

> On Tue, Apr 30, 2019 at 09:04:09AM +0200, Thomas Goirand wrote:
>> What I found the most easy way is to just use whatever branching names
>> upstream is using, and *never* store them in Salsa. If you need upstream
>> repository, you can simply run a ./debian/rules fetch-upstream-remote,
>> and most of the time, the only thing you need, is merging a tag. What I
>> push to Salsa are upstream tags only, which is enough.
>
> Why?  I strongly disagree: having the upstream tree in the same repo
> as packaging is awesome. It lets you mix patches both ways with no effort.
> Having the upstream tree at home but not pushing it deprives contributors
> who are not you of this comfort.

It's basically useless, since upstream repository is just one command
away, with the upstream URL documented in debian/rules.

Cheers,

Thomas Goirand (zigo)

12345