Ansgar <ans...@debian.org> writes:
> On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
>> I'm confused. I'm a happy user of dgit and don't have to think about
>> any of those things as part of using dgit. I choose to use branches,
>> but I certainly wouldn't have to, and merging, multiple remotes, and so
>> forth don't seem related to using dgit at all.
> How do you update the package to a new upstream release?
I think I understand what I was missing. Are you using a separate
repository for only the debian directory and merging that with an unpacked
upstream tarball without using a version control system to do so? I don't
know how that works with dgit if that's the case.
For whatever it's worth, I'm in the camp that believes the combination of
the Debian packaging and the imported upstream releases should be merged
into a single coherent Git history, because the packaging changes are
heavily dependent on the upstream changes and have an important sequencing
between upstream imports that is a key component of the total history of
the package. Having to manually stitch together two separate histories is
exactly the kind of tedious chore that I think computers are good at and
humans are bad at, so I'd rather let Git do it. YMMV, of course.
> The "dgit" repository is also separate from the "real" repository; if
> you just use "dgit clone ${something}" you won't get the current
> "master" branch (unless it happens to be identical to the last release),
> or totally different if the maintainer doesn't use dgit.
Yes, that's true, and somewhat inherent in the model. I don't know that
that's avoidable without standardizing the actual Git tree used by every
maintainer for in-progress work, which is a much harder lift. dgit stays
out of the business of investigating how the maintainer does work, at the
cost of only having visibility to the commits that have been pushed to the
archive.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
