> > I recommend as the best way to see what is happening, is to do a mock > > import on the Debian packaging repository as suggested in > > https://optimizedbyotto.com/post/debian-packaging-from-git/#import-new-upstream-versions-in-the-future > > -> > > https://optimizedbyotto.com/post/debian-source-package-git/#try-it-yourself-example-repository-galera-4-demo > > > > cd $(mktemp -d) > > gbp clone --add-upstream-vcs https://salsa.debian.org/otto/galera-4-demo.git > > cd galera-4-demo/ > > gitk --all & > > > > (gitk here is important so you see the state of the git repo and all > > the branches before the import) > > > > gbp import-orig --uscan --verbose > > (--verbose will show all the git commands that ran) > > > > After the import hit F5 in the gitk window to see the state after the > > import, and to easily inspect all branches, commits and read tag > > contents. > > Right, but that project doesn't use debian/watch mode=git? So I'm not > sure this is comparable. Here is another example.
No but it does not matter, it will still pull the upstream git. Just try to example and have `gitk --all &` open and see before and after. > jas@frallan:~/dpkg$ git clone > [email protected]:go-team/packages/golang-github-protocolbuffers-txtpbfmt.git .. > However this still creates a merge commit in the upstream branch: > > commit 57d77483f79cb82e667e3d9a1fc45c5cc470d3cc (tag: > upstream/0.0_git20251124.fcb97cc, upstream) > Merge: fba763a fcb97cc > Author: Simon Josefsson <[email protected]> > Date: Tue Jan 13 08:29:48 2026 +0100 > > New upstream version 0.0~git20251124.fcb97cc > > Sigh, so it seems I was wrong, and now I know of no way to teach 'gbp > import-orig' to behave like Ian/Sean would prefer it to do. > > To be honest, I find these GBP synthesized merge commits just noice. > What value do this add? Why can't the 'upstream' branch be the upstream > branch without any GBP modifications? Couldn't GBP support that? For > some packages, I've created such a solution manually, and GBP seems to > cope well with that once it is in place. Having the merge commit is intentional and mandatory. The branch `upstream/latest` is not supposed to have the upstream git commit, but the result of the _import_ to Debian. See https://dep-team.pages.debian.net/deps/dep14/ > Perhaps 'gbp import-ref' is the answer here. I think it is better to maintain that debian/watch is correct and uscan can fetch the package than to manually do direct pulls. If debian/metadata:upstream-vcs was mandatory and uscan could read it instead of debian/watch and there was a command like `gbp import` that always did the right thing based on what is codified in debian/* things would be easier, but that does not exist now and there are a lot of corner cases to handle, and the benefit of current uscan+debian/watch is that they do handle them all. > > I actually advocate for Debian's source code contain an upstream git > > branch that matches upstream's git commit for a release. > > Do you mean "matches" as in the same git commit identifier, or just > bit-by-bit identical content but can have the GBP merge commit? Just try the example so you can see the `gitk --all &` output, a picture tells more than a thousand words.. ... > 50.000+ packages used to be a lot to maintain in a single version > control repository. By todays standard, it isn't. I suspect if you > take all of Deabin's debian/ source directories and put them in a single > git repository, it would not be that much larger than say Guix, > Homebrew, NixOS, Fedora or some other more centralized packaging system. Yes, Debian could have a monorepo where each subdirectory is a source package name, and the contents is the equivalent of debian/ currently. But also the exact opposite where each source package in Debian is a git repo of its own, and includes the upstream origin, would have benefits too (which dgit could be). Debian will eventually probably land on either of these.
