On 17/02/26 14:56, Marc Haber wrote:
On Mon, Feb 16, 2026 at 03:29:23PM +0100, Gioele Barabucci wrote:
I have something to add, just an aside, that may influence how you
look at the results of your experiment.
Sadly, just running git log on debian/latest (which is probably the
single most important branch) only shows merge commits now.
gbp import-orig nicely took care of the differences between upstream
git and the release tarball.
`gbp import-orig` produces suboptimal merges that mix upstream and
Debian changes in an unreadable way <https://bugs.debian.org/804722>.
Could you please try to locally apply the patch proposed in that bug
report and see if produces a graph that looks (slightly) more
understandable and more sustainable in the long run?
I am not sure why the patch from that bug report will make the graph
easier to read as it doesn't reduce the number of merges. If I
understand correctly, the patch will do the merge and then add the
Debian diff in a dedicated commit.
Exactly. The graphs is only slightly easier (but longer), what is easier
to understand are the diffs. The diffs commonly produced by Git for
merge commits that also add the Debian diffs are way larger and mix two
things. To separate them you need to use `git diff -m`, for example, but
such functionalities are not available for other tools. In general, non
empty merge commits are a pain.
If you are looking at the history is because something went wrong and
you are in debugging mode. In those situations you want all changes
shown to you to be as focused as possible. Having to mentally navigate
between upstream changes, Debian changes, updated Debian patches and so
on all in one "place" is exhausting. Separate merge upstream + commit
Debian changes is just easier.
Won't this introduce a stage of
non-buildability in debian/latest, when the new upstream is already
merged and the debian stuff not yet added? I mean, especially in the
case of 3.0 (quilt) package?
In theory yes. But this is not a big issue, given that pretty much all
packages developed on a Git repo follow that pattern. You merge upstream
(1 commit + 1 upstream/ tag), do some changes (1-n commits), you test
the package, you realize something broke, you fix it (another 1-n
commits), then you release the package (1 commit + 1 debian/ tag). That
"non buildability" is always there for a short window of commits between
debian/ tags.
It's not like people develop on another branch, then squash all their
commits in master to give the illusion that everything happened at once
(like instead happens if you import past packages using `gbp import-*`).
That being said, this bug report is a classic case of many months being
lost because both sides were waiting for the other side to do something.
Guido was waiting for you to deliver a patch that would fit better into
git-buildpackage's code base, and you were waiting for him to comment on
your suggestion.
I'd add that this bug is a classic case of volunteer work. (No
complains, just a matter of fact.) The bug is from 2015, eleven years
ago. At the time I tried creating a ready-to-merge patch, but the Git
code in gbp did not implement everything that was needed for the patch,
so a proof of code was all I delivered (adding all the necessary
Git-related functionality was outside the "scratch you own issue"
radio). By the time Guido's reply came, in 2024, most of the packages
had already been converted, so I did not see, nor I see now, the idea of
spending time producing a proper patch as a good time investment: it's
at least a couple of weeks of work, and who is going to benefit from it?
maybe a handful low-popcon packages that have not been converted yet?
Regards,
--
Gioele Barabucci
