Le mar. 13 janv. 2026 à 09:19, Otto Kekäläinen <[email protected]> a écrit :
> > > 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. > uscan is smart and uses d/upstream/metadata ~/Software/debian/gpaste/salsa:debian/latest$ uscan --verbose uscan info: Found debian/upstream/metadata instead of debian/watch, trying to read it
