On Monday, 2 March 2020 11:41:07 PM AEDT Reinhard Tartler wrote:
> For instance, I value a *lot*
> that I don't have to know "quilt" very well. Instead, I can "git am"
> patches from configured remote upstream git repostiories.
Quilt is not that hard and one can argue that basic competency with quilt is
not too much to expect. But what you do in the next step is enough to satisfy
quilt:
> I value that I can do:
> # git format-patch -1 -o debian/patches/new-patch &&
> echo new-patch >> debian/patches/series'
I do that as well but it have nothing to do with GBP. Yes sometimes it is
convenient to have access to upstream git repository and dig for patches
there. But it does not have to be the same packaging repository. Those
upstream branches that you explore for patches work just as well when they
are local. You can have your private "git remote" to upstream without
burdening the actual process of building package.
How do you forward patches? I prefer to have a dedicated repository as it is
awkward to try to squash it to debian packaging repo. And again, universality
argument -- what if you contribute patch without working on a package? Would
you have two file system places to check where you keep clone of your forked
upstream repository?
> I appreciate that I can "git diff --stat" against upstream git branches
> to identify what files were stripped or not stripped from the original
> upstream sources.
There are at least two problems with that. It is not universal because
sometimes tagged release is not the same as release tarball.
When you `gbp import-orig` first, merely to compare, it is post-factum and
you will have to redo on any problems.
Also you can compare two directories with git (i.g. `git diff {dir1} {dir2}`)
and they don't even have to be committed.
> I appreciate that I can use 'git grep' to explore
> the upstream source code.
That's nice but `ack` (or just `grep`) work very well too.
You can still do `git grep` on upstream repository (regardless whether it is
a standalone repo or a "git remote").
Why would you need to push upstream to the packaging repository when anyone
can refer to upstream directly the way they like?
> Yes, that requires a high level of proficiency with the 'git' tool.
What you've mentioned requires basic competency with git.
But resolving merge conflicts and fixing inconsistencies might require
expertise high level of proficiency with git.
Years ago I remember messing up repository with `gbp import-orig` and not
being able to fix it. Even if I can fix such problems now it always a
frustration and wasted time...
> And still, I observe a momentum towards this workflow,
That worries me. Maybe I'm too late to share my notes? I should definitely
post to debian-devel...
> as most recently shown in Ian's work on
> 'dgit' and the resulting conversations on debian-devel.
I'm yet to familiarise myself with the concept and I was not following
conversations on debian-devel. But what I've seen so far did not impress me
because it looks like an evolution of the same flawed idea...
--
Best wishes,
Dmitry Smirnov.
---
What opinions the masses hold, or do not hold, is looked on as a matter of
indifference. They can be granted intellectual liberty because they have no
intellect.
-- George Orwell, 1984
Attachment:
signature.asc
Description: This is a digitally signed message part.